sles-sap-16-0-byos-v20260207-x86-64 CVE scan on 2026-02-07T02:36:10+00:00

CVE-2025-15467 Severity: Critical CVSS3 score: 9.8

Description: Issue summary: Parsing CMS AuthEnvelopedData message with maliciouslycrafted AEAD parameters can trigger a stack buffer overflow.Impact summary: A stack buffer overflow may lead to a crash, causing Denialof Service, or potentially remote code execution.When parsing CMS AuthEnvelopedData structures that use AEAD ciphers such asAES-GCM, the IV (Initialization Vector) encoded in the ASN.1 parameters iscopied into a fixed-size stack buffer without verifying that its length fitsthe destination. An attacker can supply a crafted CMS message with anoversized IV, causing a stack-based out-of-bounds write before anyauthentication or tag verification occurs.Applications and services that parse untrusted CMS or PKCS#7 content usingAEAD ciphers (e.g., S/MIME AuthEnvelopedData with AES-GCM) are vulnerable.Because the overflow occurs prior to authentication, no valid key materialis required to trigger it. While exploitability to remote code executiondepends on platform and toolchain mitigations, the stack-based writeprimitive represents a severe risk.The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by thisissue, as the CMS implementation is outside the OpenSSL FIPS moduleboundary.OpenSSL 3.6, 3.5, 3.4, 3.3 and 3.0 are vulnerable to this issue.OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.5.1 (version in image is 3.5.0-160000.3.2).

CVE-2025-11561 Severity: Important CVSS3 score: 8.8

Description: A flaw was found in the integration of Active Directory and the System Security Services Daemon (SSSD) on Linux systems. In default configurations, the Kerberos local authentication plugin (sssd_krb5_localauth_plugin) is enabled, but a fallback to the an2ln plugin is possible. This fallback allows an attacker with permission to modify certain AD attributes (such as userPrincipalName or samAccountName) to impersonate privileged users, potentially resulting in unauthorized access or privilege escalation on domain-joined Linux hosts.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libsss_idmap0 < 2.9.5-160000.3.1 (version in image is 2.9.5-160000.2.2).

CVE-2025-8067 Severity: Important CVSS3 score: 8.5

Description: A flaw was found in the Udisks daemon, where it allows unprivileged users to create loop devices using the D-BUS system. This is achieved via the loop device handler, which handles requests sent through the D-BUS interface. As two of the parameters of this handle, it receives the file descriptor list and index specifying the file where the loop device should be backed. The function itself validates the index value to ensure it isn't bigger than the maximum value allowed. However, it fails to validate the lower bound, allowing the index parameter to be a negative value. Under these circumstances, an attacker can cause the UDisks daemon to crash or perform a local privilege escalation by gaining access to files owned by privileged users.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libudisks2-0 < 2.10.1-160000.3.1 (version in image is 2.10.1-160000.2.2).

CVE-2025-38499 Severity: Important CVSS3 score: 8.4

Description: In the Linux kernel, the following vulnerability has been resolved:clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right usernsWhat we want is to verify there is that clone won't expose somethinghidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo"may be a result of MNT_LOCKED on a child, but it may also come fromlacking admin rights in the userns of the namespace mount belongs to.clone_private_mnt() checks the former, but not the latter.There's a number of rather confusing CAP_SYS_ADMIN checks in varioususerns during the mount, especially with the new mount API; they servedifferent purposes and in case of clone_private_mnt() they usually,but not always end up covering the missing check mentioned above.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-13465 Severity: Important CVSS3 score: 8.2

Description: Lodash versions 4.0.0 through 4.17.22 are vulnerable to prototype pollution in the _.unset and _.omit functions. An attacker can pass crafted paths which cause Lodash to delete methods from global prototypes.The issue permits deletion of properties but does not allow overwriting their original behavior.This issue is patched on 4.17.23

Packages affected:

cockpit > 0-0 (version in image is 340-160000.3.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2026-1299 Severity: Important CVSS3 score: 8.2

Description: The email module, specifically the "BytesGenerator" class, didn't properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized. This is only applicable if using "LiteralHeader" writing headers that don't respect email folding rules, the new behavior will reject the incorrectly folded headers in "BytesGenerator".

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313 > 0-0 (version in image is 3.13.5-160000.2.2).

CVE-2024-45337 Severity: Important CVSS3 score: 8.1

Description: Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.

Packages affected:

google-guest-agent > 0-0 (version in image is 20250116.00-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38566 Severity: Important CVSS3 score: 8.1

Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix handling of server side tls alertsScott Mayhew discovered a security exploit in NFS over TLS intls_alert_recv() due to its assumption it can read data fromthe msg iterator's kvec..kTLS implementation splits TLS non-data record payload betweenthe control message buffer (which includes the type such as TLSaler or TLS cipher change) and the rest of the payload (say TLSalert's level/description) which goes into the msg payload buffer.This patch proposes to rework how control messages are setup andused by sock_recvmsg().If no control message structure is setup, kTLS layer will read andprocess TLS data record types. As soon as it encounters a TLS controlmessage, it would return an error. At that point, NFS can setup akvec backed msg buffer and read in the control message such as aTLS alert. Msg iterator can advance the kvec pointer as a part ofthe copy process thus we need to revert the iterator before callinginto the tls_alert_recv.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38571 Severity: Important CVSS3 score: 8.1

Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix client side handling of tls alertsA security exploit was discovered in NFS over TLS in tls_alert_recvdue to its assumption that there is valid data in the msghdr'siterator's kvec.Instead, this patch proposes the rework how control messages aresetup and used by sock_recvmsg().If no control message structure is setup, kTLS layer will read andprocess TLS data record types. As soon as it encounters a TLS controlmessage, it would return an error. At that point, NFS can setup a kvecbacked control buffer and read in the control message such as a TLSalert. Scott found that a msg iterator can advance the kvec pointeras a part of the copy process thus we need to revert the iteratorbefore calling into the tls_alert_recv.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38572 Severity: Important CVSS3 score: 8.1

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: reject malicious packets in ipv6_gso_segment()syzbot was able to craft a packet with very long IPv6 extension headersleading to an overflow of skb->transport_header.This 16bit field has a limited range.Add skb_reset_transport_header_careful() helper and use itfrom ipv6_gso_segment()WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151Modules linked in:CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151Call Trace: skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110 skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 __skb_gso_segment+0x342/0x510 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950 validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000 sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329 __dev_xmit_skb net/core/dev.c:4102 [inline] __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68615 Severity: Important CVSS3 score: 8.1

Description: net-snmp is a SNMP application library, tools and daemon. Prior to versions 5.9.5 and 5.10.pre2, a specially crafted packet to an net-snmp snmptrapd daemon can cause a buffer overflow and the daemon to crash. This issue has been patched in versions 5.9.5 and 5.10.pre2.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libsnmp40 > 0-0 (version in image is 5.9.4-160000.2.2).

CVE-2025-9566 Severity: Important CVSS3 score: 8.1

Description: There's a vulnerability in podman where an attacker may use the kube play command to overwrite host files when the kube file container a Secrete or a ConfigMap volume mount and such volume contains a symbolic link to a host file path. In a successful attack, the attacker can only control the target file to be overwritten but not the content to be written into the file.Binary-Affected: podmanUpstream-version-introduced: v4.0.0Upstream-version-fixed: v5.6.1

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
podman < 5.4.2-160000.3.1 (version in image is 5.4.2-160000.2.2).

CVE-2026-1484 Severity: Important CVSS3 score: 8.1

Description: A flaw was found in the GLib Base64 encoding routine when processing very large input data. Due to incorrect use of integer types during length calculation, the library may miscalculate buffer boundaries. This can cause memory writes outside the allocated buffer. Applications that process untrusted or extremely large Base64 input using GLib may crash or behave unpredictably.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
glib2-tools < 2.84.4-160000.2.1 (version in image is 2.84.3-160000.2.2).

CVE-2026-1489 Severity: Important CVSS3 score: 8.1

Description: A flaw was found in GLib. An integer overflow vulnerability in its Unicode case conversion implementation can lead to memory corruption. By processing specially crafted and extremely large Unicode strings, an attacker could trigger an undersized memory allocation, resulting in out-of-bounds writes. This could cause applications utilizing GLib for string conversion to crash or become unstable.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
glib2-tools < 2.84.4-160000.2.1 (version in image is 2.84.3-160000.2.2).

CVE-2025-68973 Severity: Important CVSS3 score: 8.0

Description: In GnuPG before 2.4.9, armor_filter in g10/armor.c has two increments of an index variable where one is intended, leading to an out-of-bounds write for crafted input. (For ExtendedLTS, 2.2.51 and later are fixed versions.)

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
gpg2 < 2.5.5-160000.3.1 (version in image is 2.5.5-160000.2.2).

CVE-2024-53125 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: sync_linked_regs() must preserve subreg_defRange propagation must not affect subreg_def marks, otherwise thefollowing example is rewritten by verifier incorrectly whenBPF_F_TEST_RND_HI32 flag is set: 0: call bpf_ktime_get_ns call bpf_ktime_get_ns 1: r0 &= 0x7fffffff after verifier r0 &= 0x7fffffff 2: w1 = w0 rewrites w1 = w0 3: if w0 < 10 goto +0 --------------> r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: exit; if w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 exit(or zero extension of w1 at (2) is missing for architectures that require zero extension for upper register half).The following happens w/o this patch:- r0 is marked as not a subreg at (0);- w1 is marked as subreg at (2);- w1 subreg_def is overridden at (3) by copy_register_state();- w1 is read at (5) but mark_insn_zext() does not mark (2) for zero extension, because w1 subreg_def is not set;- because of BPF_F_TEST_RND_HI32 flag verifier inserts random value for hi32 bits of (2) (marked (r));- this random value is read at (5).

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-31133 Severity: Important CVSS3 score: 7.8

Description: runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7 and below, 1.3.0-rc.1 through 1.3.1, 1.4.0-rc.1 and 1.4.0-rc.2 files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container's /dev/null) was actually a real /dev/null inode when using the container's /dev/null to mask. This exposes two methods of attack: an arbitrary mount gadget, leading to host information disclosure, host denial of service, container escape, or a bypassing of maskedPaths. This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
podman < 5.4.2-160000.3.1 (version in image is 5.4.2-160000.2.2).

CVE-2025-37798 Severity: Important CVSS3 score: 7.8

Description: 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 toremove the check of qlen!=0 from both fq_codel_dequeue() andcodel_qdisc_dequeue().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38090 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:drivers/rapidio/rio_cm.c: prevent possible heap overwriteInriocm_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 butriocm_ch_send() failed to check that userspace sent sufficient data. Theresult is that riocm_ch_send() can write to fields in the rio_ch_chan_hdrwhich were outside the bounds of the space which cm_chan_msg_send()allocated.Address this by teaching riocm_ch_send() to check that the entirerio_ch_chan_hdr was copied in from userspace.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38109 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix ECVF vports unload on shutdown flowFix shutdown flow UAF when a virtual function is created on the embeddedchip (ECVF) of a BlueField device. In such case the vport acl ingresstable is not properly destroyed.ECVF functionality is independent of ecpf_vport_exists capability andthus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should nottest 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 ]---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38128 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: reject malformed HCI_CMD_SYNC commandsIn 'mgmt_hci_cmd_sync()', check whether the size of parameters passedin 'struct mgmt_cp_hci_cmd_sync' matches the total size of the data(i.e. 'sizeof(struct mgmt_cp_hci_cmd_sync)' plus trailing bytes).Otherwise, large invalid 'params_len' will cause 'hci_cmd_sync_alloc()'to do 'skb_put_data()' from an area beyond the one actually passed to'mgmt_hci_cmd_sync()'.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38137 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:PCI/pwrctrl: Cancel outstanding rescan work when unregisteringIt's possible to trigger use-after-free here by: (a) forcing rescan_work_func() to take a long time and (b) utilizing a pwrctrl driver that may be unloaded for some reasonCancel outstanding work to ensure it is finished before we allow our datastructures to be cleaned up.[bhelgaas: tidy commit log]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38141 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix dm_blk_report_zonesIf dm_get_live_table() returned NULL, dm_put_live_table() was nevercalled. Also, it is possible that md->zone_revalidate_map will changewhile calling this function. Only read it once, so that we are alwaysusing the same value. Otherwise we might miss a call todm_put_live_table().Finally, while md->zone_revalidate_map is set and a process is callingblk_revalidate_disk_zones() to set up the zone append emulationresources, it is possible that another process, perhaps triggered byblkdev_report_zones_ioctl(), will call dm_blk_report_zones(). Ifblk_revalidate_disk_zones() fails, these resources can be freed whilethe other process is still using them, causing a use-after-free error.blk_revalidate_disk_zones() will only ever be called when initiallysetting up the zone append emulation resources, such as when setting upa zoned dm-crypt table for the first time. Further table swaps will notset md->zone_revalidate_map or call blk_revalidate_disk_zones().However it must be called using the new table (referenced bymd->zone_revalidate_map) and the new queue limits while the DM device issuspended. dm_blk_report_zones() needs some way to distinguish between acall from blk_revalidate_disk_zones(), which must be allowed to usemd->zone_revalidate_map to access this not yet activated table, and allother calls to dm_blk_report_zones(), which should not be allowed whilethe device is suspended and cannot use md->zone_revalidate_map, sincethe zone resources might be freed by the process currently callingblk_revalidate_disk_zones().Solve this by tracking the process that sets md->zone_revalidate_map indm_revalidate_zones() and only allowing that process to make use of itin dm_blk_report_zones().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38180 Severity: Important CVSS3 score: 7.8

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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38226 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:media: vivid: Change the siize of the composingsyzkaller 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:2705Write of size 1440 at addr ffffc9000d0ffda0 by task vivid-000-vid-c/5304CPU: 0 UID: 0 PID: 5304 Comm: vivid-000-vid-c Not tainted 6.14.0-rc2-syzkaller-00039-g09fbf3d50205 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Call Trace: __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 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.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38227 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: Terminating the subsequent process of initialization failuresyzbot reported a slab-use-after-free Read in vidtv_mux_init. [1]After PSI initialization fails, the si member is accessed again, resultingin 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:524Read of size 8 at addr ffff88802fa42acc by task syz.2.37/6059CPU: 0 UID: 0 PID: 6059 Comm: syz.2.37 Not tainted 6.14.0-rc5-syzkaller #0Hardware name: Google Compute Engine, BIOS Google 02/12/2025Call Trace:__dump_stack lib/dump_stack.c:94 [inline]dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120print_address_description mm/kasan/report.c:408 [inline]print_report+0xc3/0x670 mm/kasan/report.c:521kasan_report+0xd9/0x110 mm/kasan/report.c:634vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline]dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564dvb_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:464task_work_run+0x14e/0x250 kernel/task_work.c:227exit_task_work include/linux/task_work.h:40 [inline]do_exit+0xad8/0x2d70 kernel/exit.c:938do_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:1096x64_sys_call+0x151f/0x1720 arch/x86/include/generated/asm/syscalls_64.h:232do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f871d58d169Code: Unable to access opcode bytes at 0x7f871d58d13f.RSP: 002b:00007fff4b19a788 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f871d58d169RDX: 0000000000000064 RSI: 0000000000000000 RDI: 0000000000000000RBP: 00007fff4b19a7ec R08: 0000000b4b19a87f R09: 00000000000927c0R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000003R13: 00000000000927c0 R14: 000000000001d553 R15: 00007fff4b19a840 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---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38257 Severity: Important CVSS3 score: 7.8

Description: 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 isdetermined by userspace via an ioctl call so the result of the product incalculation of size passed to memdup_user() may overflow.In this case the actual size of the allocated area and the valuedescribing it won't be in sync leading to various types of unpredictablebehaviour later.Use a proper memdup_array_user() helper which returns an error if anoverflow is detected. Note that it is different from when nr_apqns isinitially zero - that case is considered valid and should be handled insubsequent pkey_handler implementations.Found by Linux Verification Center (linuxtesting.org).

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38286 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: at91: Fix possible out-of-boundary accessat91_gpio_probe() doesn't check that given OF alias is not available orsomething went wrong when trying to get it. This might have consequenceswhen accessing gpio_chips array with that value as an index. Note, thatBUG() can be compiled out and hence won't actually perform the requiredchecks.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38377 Severity: Important CVSS3 score: 7.8

Description: 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 causeuse-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 Ais 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_neighstructure has been freed. Code that accesses these entries assumes thatthe first `count` entries are valid pointers, causing a use-after-freewhen it accesses the dangling pointer.Fix both issues by iterating over the array in reverse order with a fixedloop bound. This ensures that all entries are examined and that the removalof an entry doesn't affect subsequent iterations.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38396 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:fs: export anon_inode_make_secure_inode() and fix secretmem LSM bypassExport anon_inode_make_secure_inode() to allow KVM guest_memfd to createanonymous inodes with proper security context. This replaces the currentpattern of calling alloc_anon_inode() followed byinode_init_security_anon() for creating security context manually.This change also fixes a security regression in secretmem where theS_PRIVATE flag was not cleared after alloc_anon_inode(), causingLSM/SELinux checks to be bypassed for secretmem file descriptors.As guest_memfd currently resides in the KVM module, we need to export thissymbol for use outside the core kernel. In the future, guest_memfd might bemoved to core-mm, at which point the symbols no longer would have to beexported. When/if that happens is still unclear.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38453 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/msg_ring: ensure io_kiocb freeing is deferred for RCUsyzbot reports that defer/local task_work adding via msg_ring can hita request that has been freed:CPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 Not tainted 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: 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 io_req_local_work_add io_uring/io_uring.c:1184 [inline] __io_req_task_work_add+0x589/0x950 io_uring/io_uring.c:1252 io_msg_remote_post io_uring/msg_ring.c:103 [inline] io_msg_data_remote io_uring/msg_ring.c:133 [inline] __io_msg_ring_data+0x820/0xaa0 io_uring/msg_ring.c:151 io_msg_ring_data io_uring/msg_ring.c:173 [inline] io_msg_ring+0x134/0xa00 io_uring/msg_ring.c:314 __io_issue_sqe+0x17e/0x4b0 io_uring/io_uring.c:1739 io_issue_sqe+0x165/0xfd0 io_uring/io_uring.c:1762 io_wq_submit_work+0x6e9/0xb90 io_uring/io_uring.c:1874 io_worker_handle_work+0x7cd/0x1180 io_uring/io-wq.c:642 io_wq_worker+0x42f/0xeb0 io_uring/io-wq.c:696 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 which is supposed to be safe with how requests are allocated. But msgring requests alloc and free on their own, and hence must defer freeingto a sane time.Add an rcu_head and use kfree_rcu() in both spots where requests arefreed. Only the one in io_msg_tw_complete() is strictly required as ithas been visible on the other ring, but use it consistently in the otherspot as well.This should not cause any other issues outside of KASAN rightfullycomplaining about it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38476 Severity: Important CVSS3 score: 7.8

Description: 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 triggersthe splat below [0].rpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it afterskb_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/1543CPU: 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/2014Call Trace: 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)) __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:0x7f68cffb2a06Code: 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 08RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001cR10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0 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---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38488 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free in crypt_message when using async cryptoThe CVE-2024-50047 fix removed asynchronous crypto handling fromcrypt_message(), assuming all crypto operations are synchronous.However, when hardware crypto accelerators are used, this can causeuse-after-free crashes: crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &req); // Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req); // Free creq while async operation is still in progress kvfree_sensitive(creq, ...);Hardware crypto modules often implement async AEAD operations forperformance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,the operation completes asynchronously. Without crypto_wait_req(),the function immediately frees the request buffer, leading to crasheswhen the driver later accesses the freed memory.This results in a use-after-free condition when the hardware cryptodriver later accesses the freed request structure, leading to kernelcrashes with NULL pointer dereferences.The issue occurs because crypto_alloc_aead() with mask=0 doesn'tguarantee synchronous operation. Even without CRYPTO_ALG_ASYNC inthe mask, async implementations can be selected.Fix by restoring the async crypto handling:- DECLARE_CRYPTO_WAIT(wait) for completion tracking- aead_request_set_callback() for async completion notification- crypto_wait_req() to wait for operation completionThis ensures the request buffer isn't freed until the crypto operationcompletes, whether synchronous or asynchronous, while preserving theCVE-2024-50047 fix.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38490 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:net: libwx: remove duplicate page_pool_put_full_page()page_pool_put_full_page() should only be invoked when freeing Rx buffersor building a skb if the size is too short. At other times, the pagesneed to be reused. So remove the redundant page put. In the originalcode, double free pages cause kernel panic:[ 876.949834] __irq_exit_rcu+0xc7/0x130[ 876.949836] common_interrupt+0xb8/0xd0[ 876.949838] [ 876.949838] [ 876.949840] asm_common_interrupt+0x22/0x40[ 876.949841] RIP: 0010:cpuidle_enter_state+0xc2/0x420[ 876.949843] Code: 00 00 e8 d1 1d 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 cd fc 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d[ 876.949844] RSP: 0018:ffffaa7340267e78 EFLAGS: 00000246[ 876.949845] RAX: ffff9e3f135be000 RBX: 0000000000000002 RCX: 0000000000000000[ 876.949846] RDX: 000000cc2dc4cb7c RSI: ffffffff89ee49ae RDI: ffffffff89ef9f9e[ 876.949847] RBP: ffff9e378f940800 R08: 0000000000000002 R09: 00000000000000ed[ 876.949848] R10: 000000000000afc8 R11: ffff9e3e9e5a9b6c R12: ffffffff8a6d8580[ 876.949849] R13: 000000cc2dc4cb7c R14: 0000000000000002 R15: 0000000000000000[ 876.949852] ? cpuidle_enter_state+0xb3/0x420[ 876.949855] cpuidle_enter+0x29/0x40[ 876.949857] cpuidle_idle_call+0xfd/0x170[ 876.949859] do_idle+0x7a/0xc0[ 876.949861] cpu_startup_entry+0x25/0x30[ 876.949862] start_secondary+0x117/0x140[ 876.949864] common_startup_64+0x13e/0x148[ 876.949867] [ 876.949868] ---[ end trace 0000000000000000 ]---[ 876.949869] ------------[ cut here ]------------[ 876.949870] list_del corruption, ffffead40445a348->next is NULL[ 876.949873] WARNING: CPU: 14 PID: 0 at lib/list_debug.c:52 __list_del_entry_valid_or_report+0x67/0x120[ 876.949875] Modules linked in: snd_hrtimer(E) bnep(E) binfmt_misc(E) amdgpu(E) squashfs(E) vfat(E) loop(E) fat(E) amd_atl(E) snd_hda_codec_realtek(E) intel_rapl_msr(E) snd_hda_codec_generic(E) intel_rapl_common(E) snd_hda_scodec_component(E) snd_hda_codec_hdmi(E) snd_hda_intel(E) edac_mce_amd(E) snd_intel_dspcfg(E) snd_hda_codec(E) snd_hda_core(E) amdxcp(E) kvm_amd(E) snd_hwdep(E) gpu_sched(E) drm_panel_backlight_quirks(E) cec(E) snd_pcm(E) drm_buddy(E) snd_seq_dummy(E) drm_ttm_helper(E) btusb(E) kvm(E) snd_seq_oss(E) btrtl(E) ttm(E) btintel(E) snd_seq_midi(E) btbcm(E) drm_exec(E) snd_seq_midi_event(E) i2c_algo_bit(E) snd_rawmidi(E) bluetooth(E) drm_suballoc_helper(E) irqbypass(E) snd_seq(E) ghash_clmulni_intel(E) sha512_ssse3(E) drm_display_helper(E) aesni_intel(E) snd_seq_device(E) rfkill(E) snd_timer(E) gf128mul(E) drm_client_lib(E) drm_kms_helper(E) snd(E) i2c_piix4(E) joydev(E) soundcore(E) wmi_bmof(E) ccp(E) k10temp(E) i2c_smbus(E) gpio_amdpt(E) i2c_designware_platform(E) gpio_generic(E) sg(E)[ 876.949914] i2c_designware_core(E) sch_fq_codel(E) parport_pc(E) drm(E) ppdev(E) lp(E) parport(E) fuse(E) nfnetlink(E) ip_tables(E) ext4 crc16 mbcache jbd2 sd_mod sfp mdio_i2c i2c_core txgbe ahci ngbe pcs_xpcs libahci libwx r8169 phylink libata realtek ptp pps_core video wmi[ 876.949933] CPU: 14 UID: 0 PID: 0 Comm: swapper/14 Kdump: loaded Tainted: G W E 6.16.0-rc2+ #20 PREEMPT(voluntary)[ 876.949935] Tainted: [W]=WARN, [E]=UNSIGNED_MODULE[ 876.949936] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024[ 876.949936] RIP: 0010:__list_del_entry_valid_or_report+0x67/0x120[ 876.949938] Code: 00 00 00 48 39 7d 08 0f 85 a6 00 00 00 5b b8 01 00 00 00 5d 41 5c e9 73 0d 93 ff 48 89 fe 48 c7 c7 a0 31 e8 89 e8 59 7c b3 ff <0f> 0b 31 c0 5b 5d 41 5c e9 57 0d 93 ff 48 89 fe 48 c7 c7 c8 31 e8[ 876.949940] RSP: 0018:ffffaa73405d0c60 EFLAGS: 00010282[ 876.949941] RAX: 0000000000000000 RBX: ffffead40445a348 RCX: 0000000000000000[ 876.949942] RDX: 0000000000000105 RSI: 00000---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38494 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: do not bypass hid_hw_raw_requesthid_hw_raw_request() is actually useful to ensure the provided bufferand length are valid. Directly calling in the low level transport driverfunction bypassed those checks and allowed invalid paramto be used.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38495 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: ensure the allocated report buffer can contain the reserved report IDWhen the report ID is not used, the low level transport drivers expectthe first byte to be 0. However, currently the allocated buffer notaccount for that extra byte, meaning that instead of having 8 guaranteedbytes for implement to be working, we only have 7.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38555 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget : fix use-after-free in composite_dev_cleanup()1. In func configfs_composite_bind() -> composite_os_desc_req_prepare():if kmalloc fails, the pointer cdev->os_desc_req will be freed but notset to NULL. Then it will return a failure to the upper-level function.2. in func configfs_composite_bind() -> composite_dev_cleanup():it will checks whether cdev->os_desc_req is NULL. If it is not NULL, itwill attempt to use it.This will lead to a use-after-free issue.BUG: KASAN: use-after-free in composite_dev_cleanup+0xf4/0x2c0Read of size 8 at addr 0000004827837a00 by task init/1CPU: 10 PID: 1 Comm: init Tainted: G O 5.10.97-oh #1 kasan_report+0x188/0x1cc __asan_load8+0xb4/0xbc composite_dev_cleanup+0xf4/0x2c0 configfs_composite_bind+0x210/0x7ac udc_bind_to_driver+0xb4/0x1ec usb_gadget_probe_driver+0xec/0x21c gadget_dev_desc_UDC_store+0x264/0x27c

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38585 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()When gmin_get_config_var() calls efi.get_variable() and the EFI variableis larger than the expected buffer size, two behaviors combine to createa stack buffer overflow:1. gmin_get_config_var() does not return the proper error code when efi.get_variable() fails. It returns the stale 'ret' value from earlier operations instead of indicating the EFI failure.2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates *out_len to the required buffer size but writes no data to the output buffer. However, due to bug #1, gmin_get_var_int() believes the call succeeded.The caller gmin_get_var_int() then performs:- Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack- Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64- If EFI variable is >64 bytes, efi.get_variable() sets len=required_size- Due to bug #1, thinks call succeeded with len=required_size- Executes val[len] = 0, writing past end of 65-byte stack bufferThis creates a stack buffer overflow when EFI variables are larger than64 bytes. Since EFI variables can be controlled by firmware or systemconfiguration, this could potentially be exploited for code execution.Fix the bug by returning proper error codes from gmin_get_config_var()based on EFI status instead of stale 'ret' value.The gmin_get_var_int() function is called during device initializationfor camera sensor configuration on Intel Bay Trail and Cherry Trailplatforms using the atomisp camera stack.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39698 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/futex: ensure io_futex_wait() cleans up properly on failureThe io_futex_data is allocated upfront and assigned to the io_kiocbasync_data field, but the request isn't marked with REQ_F_ASYNC_DATAat that point. Those two should always go together, as the flag tellsio_uring whether the field is valid or not.Additionally, on failure cleanup, the futex handler frees the data butdoes not clear ->async_data. Clear the data and the flag in the errorpath as well.Thanks to Trend Micro Zero Day Initiative and particularly ReDress forreporting this.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39790 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Detect events pointing to unexpected TREsWhen a remote device sends a completion event to the host, it contains apointer to the consumed TRE. The host uses this pointer to process all ofthe TREs between it and the host's local copy of the ring's read pointer.This works when processing completion for chained transactions, but canlead to nasty results if the device sends an event for a single-elementtransaction with a read pointer that is multiple elements ahead of thehost's read pointer.For instance, if the host accesses an event ring while the device isupdating it, the pointer inside of the event might still point to an oldTRE. If the host uses the channel's xfer_cb() to directly free the bufferpointed to by the TRE, the buffer will be double-freed.This behavior was observed on an ep that used upstream EP stack without'commit 6f18d174b73d ("bus: mhi: ep: Update read pointer only after bufferis written")'. Where the device updated the events ring pointer beforeupdating the event contents, so it left a window where the host was able toaccess the stale data the event pointed to, before the device had thechance to update them. The usual pattern was that the host received anevent pointing to a TRE that is not immediately after the last processedone, so it got treated as if it was a chained transaction, processing allof the TREs in between the two read pointers.This commit aims to harden the host by ensuring transactions where theevent points to a TRE that isn't local_rp + 1 are chained.[mani: added stable tag and reworded commit message]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39827 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:net: rose: include node references in rose_neigh refcountCurrent implementation maintains two separate reference countingmechanisms: the 'count' field in struct rose_neigh tracks references fromrose_node structures, while the 'use' field (now refcount_t) tracksreferences from rose_sock.This patch merges these two reference counting systems using 'use' fieldfor proper reference management. Specifically, this patch adds incrementingand decrementing of rose_neigh->use when rose_neigh->count is incrementedor decremented.This patch also modifies rose_rt_free(), rose_rt_device_down() androse_clear_route() to properly release references to rose_neigh objectsbefore freeing a rose_node through rose_remove_node().These changes ensure rose_neigh structures are properly freed only whenall references, including those from rose_node structures, are released.As a result, this resolves a slab-use-after-free issue reported by Syzbot.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39898 Severity: Important CVSS3 score: 7.8

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39978 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"and then dereferences it on the next line. Two lines later, we takea mutex so I don't think this is an RCU safe region. Re-order it to dothe dereferences before queuing up the free.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39979 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fs, fix UAF in flow counter releaseFix a kernel trace [1] caused by releasing an HWS action of a local flowcounter in mlx5_cmd_hws_delete_fte(), where the HWS action refcount andmutex were not initialized and the counter struct could already be freedwhen deleting the rule.Fix it by adding the missing initializations and adding refcount for thelocal flow counter struct.[1] Kernel log: Call Trace: dump_stack_lvl+0x34/0x48 mlx5_fs_put_hws_action.part.0.cold+0x21/0x94 [mlx5_core] mlx5_fc_put_hws_action+0x96/0xad [mlx5_core] mlx5_fs_destroy_fs_actions+0x8b/0x152 [mlx5_core] mlx5_cmd_hws_delete_fte+0x5a/0xa0 [mlx5_core] del_hw_fte+0x1ce/0x260 [mlx5_core] mlx5_del_flow_rules+0x12d/0x240 [mlx5_core] ? ttwu_queue_wakelist+0xf4/0x110 mlx5_ib_destroy_flow+0x103/0x1b0 [mlx5_ib] uverbs_free_flow+0x20/0x50 [ib_uverbs] destroy_hw_idr_uobject+0x1b/0x50 [ib_uverbs] uverbs_destroy_uobject+0x34/0x1a0 [ib_uverbs] uobj_destroy+0x3c/0x80 [ib_uverbs] ib_uverbs_run_method+0x23e/0x360 [ib_uverbs] ? uverbs_finalize_object+0x60/0x60 [ib_uverbs] ib_uverbs_cmd_verbs+0x14f/0x2c0 [ib_uverbs] ? do_tty_write+0x1a9/0x270 ? file_tty_write.constprop.0+0x98/0xc0 ? new_sync_write+0xfc/0x190 ib_uverbs_ioctl+0xd7/0x160 [ib_uverbs] __x64_sys_ioctl+0x87/0xc0 do_syscall_64+0x59/0x90

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40139 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().smc_clc_prfx_set() is called during connect() and not under RCUnor RTNL.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()after kernel_getsockname().Note that the returned value of smc_clc_prfx_set() is not usedin the caller.While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()not to touch dst there.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40284 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: cancel mesh send timer when hdev removedmesh_send_done timer is not canceled when hdev is removed, which causescrash if the timer triggers after hdev is gone.Cancel the timer when MGMT removes the hdev, like other MGMT timers.Should fix the BUG: sporadically seen by BlueZ test bot(in "Mesh - Send cancel - 1" test).Log:------BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0...Freed by task 36: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240------

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-45582 Severity: Important CVSS3 score: 7.8

Description: GNU Tar through 1.35 allows file overwrite via directory traversal in crafted TAR archives, with a certain two-step process. First, the victim must extract an archive that contains a ../ symlink to a critical directory. Second, the victim must extract an archive that contains a critical file, specified via a relative pathname that begins with the symlink name and ends with that critical file's name. Here, the extraction follows the symlink and overwrites the critical file. This bypasses the protection mechanism of "Member name contains '..'" that would occur for a single TAR archive that attempted to specify the critical file via a ../ approach. For example, the first archive can contain "x -> ../../../../../home/victim/.ssh" and the second archive can contain x/authorized_keys. This can affect server applications that automatically extract any number of user-supplied TAR archives, and were relying on the blocking of traversal. This can also affect software installation processes in which "tar xf" is run more than once (e.g., when installing a package can automatically install two dependencies that are set up as untrusted tarballs instead of official packages). NOTE: the official GNU Tar manual has an otherwise-empty directory for each "tar xf" in its Security Rules of Thumb; however, third-party advice leads users to run "tar xf" more than once into the same directory.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
tar > 0-0 (version in image is 1.35-160000.2.2).

CVE-2025-52565 Severity: Important CVSS3 score: 7.8

Description: runc is a CLI tool for spawning and running containers according to the OCI specification. Versions 1.0.0-rc3 through 1.2.7, 1.3.0-rc.1 through 1.3.2, and 1.4.0-rc.1 through 1.4.0-rc.2, due to insufficient checks when bind-mounting `/dev/pts/$n` to `/dev/console` inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of `/dev/pts/$n` to `/dev/console` as configured for all containers that allocate a console). This happens after `pivot_root(2)`, so this cannot be used to write to host files directly -- however, as with CVE-2025-31133, this can load to denial of service of the host or a container breakout by providing the attacker with a writable copy of `/proc/sysrq-trigger` or `/proc/sys/kernel/core_pattern` (respectively). This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
podman < 5.4.2-160000.3.1 (version in image is 5.4.2-160000.2.2).

CVE-2025-52881 Severity: Important CVSS3 score: 7.8

Description: runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7, 1.3.2 and 1.4.0-rc.2, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (we have also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a tmpfs or theoretically other methods such as regular bind-mounts. While similar, the mitigation applied for the related CVE, CVE-2019-19921, was fairly limited and effectively only caused runc to verify that when LSM labels are written they are actually procfs files. This issue is fixed in versions 1.2.8, 1.3.3, and 1.4.0-rc.3.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
podman < 5.4.2-160000.3.1 (version in image is 5.4.2-160000.2.2).

CVE-2025-68747 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Fix UAF on kernel BO VA nodesIf the MMU is down, panthor_vm_unmap_range() might return an error.We expect the page table to be updated still, and if the MMU is blocked,the rest of the GPU should be blocked too, so no risk of accessingphysical memory returned to the system (which the current code doesn'tcover for anyway).Proceed with the rest of the cleanup instead of bailing out and leavingthe va_node inserted in the drm_mm, which leads to UAF when otheradjacent nodes are removed from the drm_mm tree.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-7345 Severity: Important CVSS3 score: 7.8

Description: A flaw exists in gdk-pixbuf within the gdk_pixbuf__jpeg_image_load_increment function (io-jpeg.c) and in glib's g_base64_encode_step (glib/gbase64.c). When processing maliciously crafted JPEG images, a heap buffer overflow can occur during Base64 encoding, allowing out-of-bounds reads from heap memory, potentially causing application crashes or arbitrary code execution.

Packages affected:

gdk-pixbuf-query-loaders < 2.42.12-160000.3.1 (version in image is 2.42.12-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-9900 Severity: Important CVSS3 score: 7.8

Description: A flaw was found in Libtiff. This vulnerability is a "write-what-where" condition, triggered when the library processes a specially crafted TIFF image file.By providing an abnormally large image height value in the file's metadata, an attacker can trick the library into writing attacker-controlled color data to an arbitrary memory location. This memory corruption can be exploited to cause a denial of service (application crash) or to achieve arbitrary code execution with the permissions of the user.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libtiff6 < 4.7.1-160000.1.1 (version in image is 4.7.0-160000.2.2).

CVE-2026-0861 Severity: Important CVSS3 score: 7.8

Description: Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) in the GNU C Library version 2.30 to 2.42 may result in an integer overflow, which could consequently result in a heap corruption.Note that the attacker must have control over both, the size as well as the alignment arguments of the memalign function to be able to exploit this. The size parameter must be close enough to PTRDIFF_MAX so as to overflow size_t along with the large alignment argument. This limits the malicious inputs for the alignment for memalign to the range [1<<62+ 1, 1<<63] and exactly 1<<63 for posix_memalign and aligned_alloc.Typically the alignment argument passed to such functions is a known constrained quantity (e.g. page size, block size, struct sizes) and is not attacker controlled, because of which this may not be easily exploitable in practice. An application bug could potentially result in the input alignment being too large, e.g. due to a different buffer overflow or integer overflow in the application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
glibc < 2.40-160000.3.1 (version in image is 2.40-160000.2.2).

CVE-2026-24882 Severity: Important CVSS3 score: 7.8

Description: In GnuPG before 2.5.17, a stack-based buffer overflow exists in tpm2daemon during handling of the PKDECRYPT command for TPM-backed RSA and ECC keys.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
gpg2 < 2.5.5-160000.4.1 (version in image is 2.5.5-160000.2.2).

CVE-2025-13601 Severity: Important CVSS3 score: 7.7

Description: A heap-based buffer overflow problem was found in glib through an incorrect calculation of buffer size in the g_escape_uri_string() function. If the string to escape contains a very large number of unacceptable characters (which would need escaping), the calculation of the length of the escaped string could overflow, leading to a potential write off the end of the newly allocated string.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
glib2-tools < 2.84.4-160000.1.1 (version in image is 2.84.3-160000.2.2).

CVE-2025-38471 Severity: Important CVSS3 score: 7.7

Description: In the Linux kernel, the following vulnerability has been resolved:tls: always refresh the queue when reading sockAfter recent changes in net-next TCP compacts skbs much moreaggressively. This unearthed a bug in TLS where we may tryto operate on an old skb when checking if all skbs in thequeue 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/0x1f0Always reload the queue, fast path is to have the record in the queuewhen we wake, anyway (IOW the path going down "if !strp->stm.full_len").

Packages affected:

kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2024-4067 Severity: Important CVSS3 score: 7.5

Description: The NPM package `micromatch` prior to 4.0.8 is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in `micromatch.braces()` in `index.js` because the pattern `.*` will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persists. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching. This issue was fixed in version 4.0.8.

Packages affected:

cockpit > 0-0 (version in image is 340-160000.3.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-11187 Severity: Important CVSS3 score: 7.5

Description: Issue summary: PBMAC1 parameters in PKCS#12 files are missing validationwhich can trigger a stack-based buffer overflow, invalid pointer or NULLpointer dereference during MAC verification.Impact summary: The stack buffer overflow or NULL pointer dereference maycause a crash leading to Denial of Service for an application that parsesuntrusted PKCS#12 files. The buffer overflow may also potentially enablecode execution depending on platform mitigations.When verifying a PKCS#12 file that uses PBMAC1 for the MAC, the PBKDF2salt and keylength parameters from the file are used without validation.If the value of keylength exceeds the size of the fixed stack buffer usedfor the derived key (64 bytes), the key derivation will overflow the buffer.The overflow length is attacker-controlled. Also, if the salt parameter isnot an OCTET STRING type this can lead to invalid or NULL pointerdereference.Exploiting this issue requires a user or application to processa maliciously crafted PKCS#12 file. It is uncommon to accept untrustedPKCS#12 files in applications as they are usually used to store privatekeys which are trusted by definition. For this reason the issue was assessedas Moderate severity.The FIPS modules in 3.6, 3.5 and 3.4 are not affected by this issue, asPKCS#12 processing is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5 and 3.4 are vulnerable to this issue.OpenSSL 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue as they donot support PBMAC1 in PKCS#12.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.5.1 (version in image is 3.5.0-160000.3.2).

CVE-2025-11468 Severity: Important CVSS3 score: 7.5

Description: When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313 > 0-0 (version in image is 3.13.5-160000.2.2).

CVE-2025-11731 Severity: Important CVSS3 score: 7.5

Description: A flaw was found in the exsltFuncResultComp() function of libxslt, which handles EXSLT elements during stylesheet parsing. Due to improper type handling, the function may treat an XML document node as a regular XML element node, resulting in a type confusion. This can cause unexpected memory reads and potential crashes. While difficult to exploit, the flaw could lead to application instability or denial of service.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libexslt0 < 1.1.43-160000.3.1 (version in image is 1.1.43-160000.2.2).

CVE-2025-15468 Severity: Important CVSS3 score: 7.5

Description: Issue summary: If an application using the SSL_CIPHER_find() function ina QUIC protocol client or server receives an unknown cipher suite fromthe peer, a NULL dereference occurs.Impact summary: A NULL pointer dereference leads to abnormal termination ofthe running process causing Denial of Service.Some applications call SSL_CIPHER_find() from the client_hello_cb callbackon the cipher ID received from the peer. If this is done with an SSL objectimplementing the QUIC protocol, NULL pointer dereference will happen ifthe examined cipher ID is unknown or unsupported.As it is not very common to call this function in applications using the QUIC protocol and the worst outcome is Denial of Service, the issue was assessedas Low severity.The vulnerable code was introduced in the 3.2 version with the additionof the QUIC protocol support.The FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue,as the QUIC implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.5.1 (version in image is 3.5.0-160000.3.2).

CVE-2025-22869 Severity: Important CVSS3 score: 7.5

Description: SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.

Packages affected:

google-guest-agent > 0-0 (version in image is 20250116.00-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38089 Severity: Important CVSS3 score: 7.5

Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: handle SVC_GARBAGE during svc auth processing as auth errortianshuo han reported a remotely-triggerable crash if the client sends akernel RPC server a specially crafted packet. If decoding the RPC replyfails in such a way that SVC_GARBAGE is returned without setting therq_accept_statp pointer, then that pointer can be dereferenced and avalue stored there.If it's the first time the thread has processed an RPC, then thatpointer 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_authenticateor pg_authenticate as if it should send a GARBAGE_ARGS reply. RFC 5531says that if authentication fails that the RPC should be rejectedinstead with a status of AUTH_ERR.Handle a SVC_GARBAGE return as an AUTH_ERROR, with a reason ofAUTH_BADCRED instead of returning GARBAGE_ARGS in that case. Thissidesteps the whole problem of touching the rpc_accept_statp pointer inthis situation and avoids the crash.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38181 Severity: Important CVSS3 score: 7.5

Description: 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 allocatinga CALIPSO option. [0]The NULL is of struct sock, which was fetched by sk_to_full_sk() incalipso_req_setattr().Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"),reqsk->rsk_listener could be NULL when SYN Cookie is returned to itsclient, 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_listener1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookiefor CALIPSO. 3) is also no go as there have been many efforts to reduceatomic 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 willcare 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 NOPTIKASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 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:2806Code: 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 8bRSP: 0018:ffff88811af89038 EFLAGS: 00010216RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640eR10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0PKRU: 80000000Call Trace: 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---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38560 Severity: Important CVSS3 score: 7.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/sev: Evict cache lines during SNP memory validationAn SNP cache coherency vulnerability requires a cache line evictionmitigation when validating memory after a page state change to private.The specific mitigation is to touch the first and last byte of each 4Kpage that is being validated. There is no need to perform the mitigationwhen performing a page state change to shared and rescinding validation.CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bitthat, when set, indicates that the software mitigation for thisvulnerability is not needed.Implement the mitigation and invoke it when validating memory (making itprivate) and the COHERENCY_SFW_NO bit is not set, indicating the SNPguest is vulnerable.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38563 Severity: Important CVSS3 score: 7.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Prevent VMA split of buffer mappingsThe perf mmap code is careful about mmap()'ing the user page with theringbuffer and additionally the auxiliary buffer, when the event supportsit. Once the first mapping is established, subsequent mapping have to usethe same offset and the same size in both cases. The reference counting forthe ringbuffer and the auxiliary buffer depends on this being correct.Though perf does not prevent that a related mapping is split via mmap(2),munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,which take reference counts, but then the subsequent perf_mmap_close()calls are not longer fulfilling the offset and size checks. This leads toreference count leaks.As perf already has the requirement for subsequent mappings to match theinitial mapping, the obvious consequence is that VMA splits, caused byresizing of a mapping or partial unmapping, have to be prevented.Implement the vm_operations_struct::may_split() callback and returnunconditionally -EINVAL.That ensures that the mapping offsets and sizes cannot be changed after thefact. Remapping to a different fixed address with the same size is stillpossible as it takes the references for the new mapping and drops those ofthe old mapping.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39890 Severity: Important CVSS3 score: 7.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: fix memory leak in ath12k_service_ready_ext_eventCurrently, in ath12k_service_ready_ext_event(), svc_rdy_ext.mac_phy_capsis not freed in the failure case, causing a memory leak. The followingtrace is observed in kmemleak:unreferenced object 0xffff8b3eb5789c00 (size 1024): comm "softirq", pid 0, jiffies 4294942577 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 7b 00 00 10 ............{... 01 00 00 00 00 00 00 00 01 00 00 00 1f 38 00 00 .............8.. backtrace (crc 44e1c357): __kmalloc_noprof+0x30b/0x410 ath12k_wmi_mac_phy_caps_parse+0x84/0x100 [ath12k] ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k] ath12k_wmi_svc_rdy_ext_parse+0x308/0x4c0 [ath12k] ath12k_wmi_tlv_iter+0x5e/0x140 [ath12k] ath12k_service_ready_ext_event.isra.0+0x44/0xd0 [ath12k] ath12k_wmi_op_rx+0x2eb/0xd70 [ath12k] ath12k_htc_rx_completion_handler+0x1f4/0x330 [ath12k] ath12k_ce_recv_process_cb+0x218/0x300 [ath12k] ath12k_pci_ce_workqueue+0x1b/0x30 [ath12k] process_one_work+0x219/0x680 bh_worker+0x198/0x1f0 tasklet_action+0x13/0x30 handle_softirqs+0xca/0x460 __irq_exit_rcu+0xbe/0x110 irq_exit_rcu+0x9/0x30Free svc_rdy_ext.mac_phy_caps in the error case to fix this memory leak.Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40129 Severity: Important CVSS3 score: 7.5

Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix null pointer dereference on zero-length checksumIn xdr_stream_decode_opaque_auth(), zero-length checksum.len causeschecksum.data to be set to NULL. This triggers a NPD when accessingchecksum.data in gss_krb5_verify_mic_v2(). This patch ensures thatthe value of checksum.len is not less than XDR_UNIT.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40204 Severity: Important CVSS3 score: 7.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-47273 Severity: Important CVSS3 score: 7.5

Description: setuptools is a package that allows users to download, build, install, upgrade, and uninstall Python packages. A path traversal vulnerability in `PackageIndex` is present in setuptools prior to version 78.1.1. An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to remote code execution depending on the context. Version 78.1.1 fixes the issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313-setuptools > 0-0 (version in image is 78.1.1-160000.2.2).

CVE-2025-47913 Severity: Important CVSS3 score: 7.5

Description: SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
podman > 0-0 (version in image is 5.4.2-160000.2.2).

CVE-2025-58060 Severity: Important CVSS3 score: 7.5

Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.12 and earlier, when the `AuthType` is set to anything but `Basic`, if the request contains an `Authorization: Basic ...` header, the password is not checked. This results in authentication bypass. Any configuration that allows an `AuthType` that is not `Basic` is affected. Version 2.4.13 fixes the issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
cups-config > 0-0 (version in image is 2.4.11-160000.2.2).

CVE-2025-59375 Severity: Important CVSS3 score: 7.5

Description: libexpat in Expat before 2.7.2 allows attackers to trigger large dynamic memory allocations via a small document that is submitted for parsing.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libexpat1 < 2.7.1-160000.3.1 (version in image is 2.7.1-160000.2.2).

CVE-2025-61919 Severity: Important CVSS3 score: 7.5

Description: Rack is a modular Ruby web server interface. Prior to versions 2.2.20, 3.1.18, and 3.2.3, `Rack::Request#POST` reads the entire request body into memory for `Content-Type: application/x-www-form-urlencoded`, calling `rack.input.read(nil)` without enforcing a length or cap. Large request bodies can therefore be buffered completely into process memory before parsing, leading to denial of service (DoS) through memory exhaustion. Users should upgrade to Rack version 2.2.20, 3.1.18, or 3.2.3, anu of which enforces form parameter limits using `query_parser.bytesize_limit`, preventing unbounded reads of `application/x-www-form-urlencoded` bodies. Additionally, enforce strict maximum body size at the proxy or web server layer (e.g., Nginx `client_max_body_size`, Apache `LimitRequestBody`).

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
hawk2 < 2.7.0+git.1742310530.bfcd0e2c-160000.3.1 (version in image is 2.7.0+git.1742310530.bfcd0e2c-160000.2.2).

CVE-2025-68775 Severity: Important CVSS3 score: 7.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/handshake: duplicate handshake cancellations leak socketWhen a handshake request is cancelled it is removed from thehandshake_net->hn_requests list, but it is still present in thehandshake_rhashtbl until it is destroyed.If a second cancellation request arrives for the same handshake request,then remove_pending() will return false... and assumingHANDSHAKE_F_REQ_COMPLETED isn't set in req->hr_flags, we'll continueprocessing through the out_true label, where we put another reference onthe sock and a refcount underflow occurs.This can happen for example if a handshake times out - particularly ifthe SUNRPC client sends the AUTH_TLS probe to the server but doesn'tfollow it up with the ClientHello due to a problem with tlshd. When thetimeout is hit on the server, the server will send a FIN, which triggersa cancellation request via xs_reset_transport(). When the timeout ishit on the client, another cancellation request happens viaxs_tls_handshake_sync().Add a test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED) in the pending cancelpath so duplicate cancels can be detected.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68813 Severity: Important CVSS3 score: 7.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix ipv4 null-ptr-deref in route error pathThe IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure()without ensuring skb->dev is set, leading to a NULL pointer dereferencein fib_compute_spec_dst() when ipv4_link_failure() attempts to sendICMP destination unreachable messages.The issue emerged after commit ed0de45a1008 ("ipv4: recompile ip optionsin ipv4_link_failure") started calling __ip_options_compile() fromipv4_link_failure(). This code path eventually calls fib_compute_spec_dst()which dereferences skb->dev. An attempt was made to fix the NULL skb->devdereference in commit 0113d9c9d1cc ("ipv4: fix null-deref inipv4_link_failure"), but it only addressed the immediate dev_net(skb->dev)dereference by using a fallback device. The fix was incomplete becausefib_compute_spec_dst() later in the call chain still accesses skb->devdirectly, which remains NULL when IPVS calls dst_link_failure().The crash occurs when:1. IPVS processes a packet in NAT mode with a misconfigured destination2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route3. The error path calls dst_link_failure(skb) with skb->dev == NULL4. ipv4_link_failure() -> ipv4_send_dest_unreach() -> __ip_options_compile() -> fib_compute_spec_dst()5. fib_compute_spec_dst() dereferences NULL skb->devApply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fixipv6 route unreach panic"): set skb->dev from skb_dst(skb)->dev beforecalling dst_link_failure().KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f]CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233RIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285Call Trace: spec_dst_fill net/ipv4/ip_options.c:232 spec_dst_fill net/ipv4/ip_options.c:229 __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330 ipv4_send_dest_unreach net/ipv4/route.c:1252 ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265 dst_link_failure include/net/dst.h:437 __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412 ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-69223 Severity: Important CVSS3 score: 7.5

Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below allow a zip bomb to be used to execute a DoS against the AIOHTTP server. An attacker may be able to send a compressed request that when decompressed by AIOHTTP could exhaust the host's memory. This issue is fixed in version 3.13.3.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313-aiohttp > 0-0 (version in image is 3.11.16-160000.2.2).

CVE-2025-69227 Severity: Important CVSS3 score: 7.5

Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below allow for an infinite loop to occur when assert statements are bypassed, resulting in a DoS attack when processing a POST body. If optimizations are enabled (-O or PYTHONOPTIMIZE=1), and the application includes a handler that uses the Request.post() method, then an attacker may be able to execute a DoS attack with a specially crafted message. This issue is fixed in version 3.13.3.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313-aiohttp > 0-0 (version in image is 3.11.16-160000.2.2).

CVE-2025-69228 Severity: Important CVSS3 score: 7.5

Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below allow a request to be crafted in such a way that an AIOHTTP server's memory fills up uncontrollably during processing. If an application includes a handler that uses the Request.post() method, an attacker may be able to freeze the server by exhausting the memory. This issue is fixed in version 3.13.3.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313-aiohttp > 0-0 (version in image is 3.11.16-160000.2.2).

CVE-2025-69229 Severity: Important CVSS3 score: 7.5

Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. In versions 3.13.2 and below, handling of chunked messages can result in excessive blocking CPU usage when receiving a large number of chunks. If an application makes use of the request.read() method in an endpoint, it may be possible for an attacker to cause the server to spend a moderate amount of blocking CPU time (e.g. 1 second) while processing the request. This could potentially lead to DoS as the server would be unable to handle other requests during that time. This issue is fixed in version 3.13.3.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313-aiohttp > 0-0 (version in image is 3.11.16-160000.2.2).

CVE-2025-71085 Severity: Important CVSS3 score: 7.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()There exists a kernel oops caused by a BUG_ON(nhead < 0) atnet/core/skbuff.c:2232 in pskb_expand_head().This bug is triggered as part of the calipso_skbuff_setattr()routine when skb_cow() is passed headroom > INT_MAX(i.e. (int)(skb_headroom(skb) + len_delta) < 0).The root cause of the bug is due to an implicit integer cast in__skb_cow(). The check (headroom > skb_headroom(skb)) is meant to ensurethat delta = headroom - skb_headroom(skb) is never negative, otherwisewe will trigger a BUG_ON in pskb_expand_head(). However, ifheadroom > INT_MAX and delta <= -NET_SKB_PAD, the check passes, deltabecomes negative, and pskb_expand_head() is passed a negative value fornhead.Fix the trigger condition in calipso_skbuff_setattr(). Avoid passing"negative" headroom sizes to skb_cow() within calipso_skbuff_setattr()by only using skb_cow() to grow headroom.PoC: Using `netlabelctl` tool: netlabelctl map del default netlabelctl calipso add pass doi:7 netlabelctl map add default address:0::1/128 protocol:calipso,7 Then run the following PoC: int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP); // setup msghdr int cmsg_size = 2; int cmsg_len = 0x60; struct msghdr msg; struct sockaddr_in6 dest_addr; struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1, sizeof(struct cmsghdr) + cmsg_len); msg.msg_name = &dest_addr; msg.msg_namelen = sizeof(dest_addr); msg.msg_iov = NULL; msg.msg_iovlen = 0; msg.msg_control = cmsg; msg.msg_controllen = cmsg_len; msg.msg_flags = 0; // setup sockaddr dest_addr.sin6_family = AF_INET6; dest_addr.sin6_port = htons(31337); dest_addr.sin6_flowinfo = htonl(31337); dest_addr.sin6_addr = in6addr_loopback; dest_addr.sin6_scope_id = 31337; // setup cmsghdr cmsg->cmsg_len = cmsg_len; cmsg->cmsg_level = IPPROTO_IPV6; cmsg->cmsg_type = IPV6_HOPOPTS; char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr); hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80 sendmsg(fd, &msg, 0);

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71120 Severity: Important CVSS3 score: 7.5

Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verfA zero length gss_token results in pages == 0 and in_token->pages[0]is NULL. The code unconditionally evaluatespage_address(in_token->pages[0]) for the initial memcpy, which candereference NULL even when the copy length is 0. Guard the firstmemcpy so it only runs when length > 0.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-9086 Severity: Important CVSS3 score: 7.5

Description: 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 boundaryThe bug either causes a crash or it potentially makes the comparison come tothe wrong conclusion and lets the clear-text site override the contents of thesecure cookie, contrary to expectations and depending on the memory contentsimmediately following the single-byte allocation that holds the path.The presumed and correct behavior would be to plainly ignore the second set ofthe cookie since it was already set as secure on a secure host so overridingit on an insecure host should not be okay.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
curl < 8.14.1-160000.3.1 (version in image is 8.14.1-160000.2.2).

CVE-2025-9230 Severity: Important CVSS3 score: 7.5

Description: Issue summary: An application trying to decrypt CMS messages encrypted usingpassword based encryption can trigger an out-of-bounds read and write.Impact summary: This out-of-bounds read may trigger a crash which leads toDenial of Service for an application. The out-of-bounds write can causea memory corruption which can have various consequences includinga Denial of Service or Execution of attacker-supplied code.Although the consequences of a successful exploit of this vulnerabilitycould be severe, the probability that the attacker would be able toperform it is low. Besides, password based (PWRI) encryption support in CMSmessages is very rarely used. For that reason the issue was assessed asModerate severity according to our Security Policy.The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by thisissue, as the CMS implementation is outside the OpenSSL FIPS moduleboundary.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.4.1 (version in image is 3.5.0-160000.3.2).

CVE-2026-0672 Severity: Important CVSS3 score: 7.5

Description: When using http.cookies.Morsel, user-controlled cookie values and parameters can allow injecting HTTP headers into messages. Patch rejects all control characters within cookie names, values, and parameters.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313 > 0-0 (version in image is 3.13.5-160000.2.2).

CVE-2026-21226 Severity: Important CVSS3 score: 7.5

Description: Unknown.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313-azure-core > 0-0 (version in image is 1.32.0-160000.2.2).

CVE-2026-23490 Severity: Important CVSS3 score: 7.5

Description: pyasn1 is a generic ASN.1 library for Python. Prior to 0.6.2, a Denial-of-Service issue has been found that leads to memory exhaustion from malformed RELATIVE-OID with excessive continuation octets. This vulnerability is fixed in 0.6.2.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313-pyasn1 < 0.6.1-160000.3.1 (version in image is 0.6.1-160000.2.2).

CVE-2026-24883 Severity: Important CVSS3 score: 7.5

Description: In GnuPG before 2.5.17, a long signature packet length causes parse_signature to return success with sig->data[] set to a NULL value, leading to a denial of service (application crash).

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
gpg2 < 2.5.5-160000.4.1 (version in image is 2.5.5-160000.2.2).

CVE-2025-38616 Severity: Important CVSS3 score: 7.4

Description: In the Linux kernel, the following vulnerability has been resolved:tls: handle data disappearing from under the TLS ULPTLS expects that it owns the receive queue of the TCP socket.This cannot be guaranteed in case the reader of the TCP socketentered before the TLS ULP was installed, or uses some non-standardread API (eg. zerocopy ones). Replace the WARN_ON() and a buggyearly exit (which leaves anchor pointing to a freed skb) with realerror handling. Wipe the parsing state and tell the reader to retry.We already reload the anchor every time we (re)acquire the socket lock,so the only condition we need to avoid is an out of bounds read(not having enough bytes in the socket for previously parsed record len).If some data was read from under TLS but there's enough in the queuewe'll reload and decrypt what is most likely not a valid TLS record.Leading to some undefined behavior from TLS perspective (corruptinga stream? missing an alert? missing an attack?) but no kernel crashshould take place.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-45768 Severity: Important CVSS3 score: 7.4

Description: pyjwt v2.10.1 was discovered to contain weak encryption. NOTE: this is disputed by the Supplier because the key length is chosen by the application that uses the library (admittedly, library users may benefit from a minimum value and a mechanism for opting in to strict enforcement).

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313-PyJWT > 0-0 (version in image is 2.10.1-160000.2.2).

CVE-2025-4953 Severity: Important CVSS3 score: 7.4

Description: A flaw was found in Podman. In a Containerfile or Podman, data written to RUN --mount=type=bind mounts during the podman build is not discarded. This issue can lead to files created within the container appearing in the temporary build context directory on the host, leaving the created files accessible.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
podman > 0-0 (version in image is 5.4.2-160000.2.2).

CVE-2025-38350 Severity: Important CVSS3 score: 7.3

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Always pass notifications when child class becomes emptyCertain classful qdiscs may invoke their classes' dequeue handler on anenqueue operation. This may unexpectedly empty the child qdisc and thusmake an in-flight class passive via qlen_notify(). Most qdiscs do notexpect such behaviour at this point in time and may re-activate theclass eventually anyways which will lead to a use-after-free.The referenced fix commit attempted to fix this behavior for the HFSCcase by moving the backlog accounting around, though this turned out tobe 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:8888Since backlog accounting issues leading to a use-after-frees on staleclass pointers is a recurring pattern at this point, this patch takesa different approach. Instead of trying to fix the accounting, the patchensures that qdisc_tree_reduce_backlog always calls qlen_notify whenthe child qdisc is empty. This solves the problem because deletion ofqdiscs always involves a call to qdisc_reset() and / orqdisc_purge_queue() which ultimately resets its qlen to 0 thus causingthe following qdisc_tree_reduce_backlog() to report to the parent. Notethat this may call qlen_notify on passive classes multiple times. Thisis not a problem after the recent patch series that made all theclassful qdiscs qlen_notify() handlers idempotent.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68284 Severity: Important CVSS3 score: 7.3

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: prevent potential out-of-bounds writes in handle_auth_session_key()The len field originates from untrusted network packets. Boundarychecks have been added to prevent potential out-of-bounds writes whendecrypting the connection secret or processing service tickets.[ idryomov: changelog ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-8176 Severity: Important CVSS3 score: 7.3

Description: A vulnerability was found in LibTIFF up to 4.7.0. It has been declared as critical. This vulnerability affects the function get_histogram of the file tools/tiffmedian.c. The manipulation leads to use after free. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The patch is identified as fe10872e53efba9cc36c66ac4ab3b41a839d5172. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libtiff6 < 4.7.1-160000.1.1 (version in image is 4.7.0-160000.2.2).

CVE-2025-14087 Severity: Important CVSS3 score: 7.1

Description: A flaw was found in GLib (Gnome Lib). This vulnerability allows a remote attacker to cause heap corruption, leading to a denial of service or potential code execution via a buffer-underflow in the GVariant parser when processing maliciously crafted input strings.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
glib2-tools < 2.84.4-160000.1.1 (version in image is 2.84.3-160000.2.2).

CVE-2025-38421 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86/amd: pmf: Use device managed allocationsIf setting up smart PC fails for any reason then this can lead toa double free when unloading amd-pmf. This is because dev->buf wasfreed but never set to NULL and is again freed in amd_pmf_remove().To avoid subtle allocation bugs in failures leading to a double freechange all allocations into device managed allocations.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38475 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:smc: Fix various oops due to inet_sock type confusion.syzbot reported weird splats [0][1] in cipso_v4_sock_setattr() whilefreeing inet_sk(sk)->inet_opt.The address was freed multiple times even though it was read-only memory.cipso_v4_sock_setattr() did nothing wrong, and the root cause was typeconfusion.The cited commit made it possible to create smc_sock as an INET socket.The issue is that struct smc_sock does not have struct inet_sock as thefirst member but hijacks AF_INET and AF_INET6 sk_family, which confusesvarious places.In this case, inet_sock.inet_opt was actually smc_sock.clcsk_data_ready(),which is an address of a function in the text segment. $ pahole -C inet_sock vmlinux struct inet_sock { ... struct ip_options_rcu * inet_opt; /* 784 8 */ $ pahole -C smc_sock vmlinux struct smc_sock { ... void (*clcsk_data_ready)(struct sock *); /* 784 8 */The same issue for another field was reported before. [2][3]At that time, an ugly hack was suggested [4], but it makes both INETand SMC code error-prone and hard to change.Also, yet another variant was fixed by a hacky commit 98d4435efcbf3("net/smc: prevent NULL pointer dereference in txopt_get").Instead of papering over the root cause by such hacks, we should notallow non-INET socket to reuse the INET infra.Let's add inet_sock as the first member of smc_sock.[0]:kvfree_call_rcu(): Double-freed call. rcu_head 000000006921da73WARNING: CPU: 0 PID: 6718 at mm/slab_common.c:1956 kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955Modules linked in:CPU: 0 UID: 0 PID: 6718 Comm: syz.0.17 Tainted: G W 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPTTainted: [W]=WARNHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955lr : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955sp : ffff8000a03a7730x29: ffff8000a03a7730 x28: 00000000fffffff5 x27: 1fffe000184823d3x26: dfff800000000000 x25: ffff0000c2411e9e x24: ffff0000dd88da00x23: ffff8000891ac9a0 x22: 00000000ffffffea x21: ffff8000891ac9a0x20: ffff8000891ac9a0 x19: ffff80008afc2480 x18: 00000000ffffffffx17: 0000000000000000 x16: ffff80008ae642c8 x15: ffff700011ede14cx14: 1ffff00011ede14c x13: 0000000000000004 x12: ffffffffffffffffx11: ffff700011ede14c x10: 0000000000ff0100 x9 : 5fa3c1ffaf0ff000x8 : 5fa3c1ffaf0ff000 x7 : 0000000000000001 x6 : 0000000000000001x5 : ffff8000a03a7078 x4 : ffff80008f766c20 x3 : ffff80008054d360x2 : 0000000000000000 x1 : 0000000000000201 x0 : 0000000000000000Call trace: kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 (P) cipso_v4_sock_setattr+0x2f0/0x3f4 net/ipv4/cipso_ipv4.c:1914 netlbl_sock_setattr+0x240/0x334 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa8/0x158 security/smack/smack_lsm.c:2581 smack_inode_setsecurity+0x378/0x430 security/smack/smack_lsm.c:2912 security_inode_setsecurity+0x118/0x3c0 security/security.c:2706 __vfs_setxattr_noperm+0x174/0x5c4 fs/xattr.c:251 __vfs_setxattr_locked+0x1ec/0x218 fs/xattr.c:295 vfs_setxattr+0x158/0x2ac fs/xattr.c:321 do_setxattr fs/xattr.c:636 [inline] file_setxattr+0x1b8/0x294 fs/xattr.c:646 path_setxattrat+0x2ac/0x320 fs/xattr.c:711 __do_sys_fsetxattr fs/xattr.c:761 [inline] __se_sys_fsetxattr fs/xattr.c:758 [inline] __arm64_sys_fsetxattr+0xc0/0xdc fs/xattr.c:758 __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/0x180 arch/arm64/kernel/entry-common.c:879 el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600[---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38608 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktlsWhen sending plaintext data, we initially calculated the correspondingciphertext length. However, if we later reduced the plaintext data lengthvia socket policy, we failed to recalculate the ciphertext length.This results in transmitting buffers containing uninitialized data duringciphertext transmission.This causes uninitialized bytes to be appended after a complete"Application Data" packet, leading to errors on the receiving end whenparsing TLS record.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38619 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:media: ti: j721e-csi2rx: fix list_del corruptionIf ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer ismarked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue.This causes the same buffer to be retried in the next iteration, resultingin a double list_del() and eventual list corruption.Fix this by removing the buffer from the queue before callingvb2_buffer_done() on error.This resolves a crash due to list_del corruption:[ 37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA[ 37.832187] slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048[ 37.839761] list_del corruption. next->prev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428)[ 37.850799] ------------[ cut here ]------------[ 37.855424] kernel BUG at lib/list_debug.c:65![ 37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP[ 37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul[ 37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY[ 37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT)[ 37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114[ 37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114[ 37.914059] sp : ffff800080003db0[ 37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000[ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122[ 37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0[ 37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a[ 37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720[ 37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea[ 37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568[ 37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff[ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000[ 37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d[ 37.988832] Call trace:[ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P)[ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4[ 38.001419] udma_vchan_complete+0x1e0/0x344[ 38.005705] tasklet_action_common+0x118/0x310[ 38.010163] tasklet_action+0x30/0x3c[ 38.013832] handle_softirqs+0x10c/0x2e0[ 38.017761] __do_softirq+0x14/0x20[ 38.021256] ____do_softirq+0x10/0x20[ 38.024931] call_on_irq_stack+0x24/0x60[ 38.028873] do_softirq_own_stack+0x1c/0x40[ 38.033064] __irq_exit_rcu+0x130/0x15c[ 38.036909] irq_exit_rcu+0x10/0x20[ 38.040403] el1_interrupt+0x38/0x60[ 38.043987] el1h_64_irq_handler+0x18/0x24[ 38.048091] el1h_64_irq+0x6c/0x70[ 38.051501] default_idle_call+0x34/0xe0 (P)[ 38.055783] do_idle+0x1f8/0x250[ 38.059021] cpu_startup_entry+0x34/0x3c[ 38.062951] rest_init+0xb4/0xc0[ 38.066186] console_on_rootfs+0x0/0x6c[ 38.070031] __primary_switched+0x88/0x90[ 38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000)[ 38.080168] ---[ end trace 0000000000000000 ]---[ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt[ 38.092197] SMP: stopping secondary CPUs[ 38.096139] Kernel Offset: disabled[ 38.099631] CPU features: 0x0000,00002000,02000801,0400420b[ 38.105202] Memory Limit: none[ 38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38659 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: No more self recoveryWhen a node withdraws and it turns out that it is the only node that hasthe filesystem mounted, gfs2 currently tries to replay the local journalto bring the filesystem back into a consistent state. Not only is thata very bad idea, it has also never worked because gfs2_recover_func()will refuse to do anything during a withdraw.However, before even getting to this point, gfs2_recover_func()dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free beforecommit 04133b607a78 ("gfs2: Prevent double iput for journal on error")and is a NULL pointer dereference since then.Simply get rid of self recovery to fix that.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38678 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: reject duplicate device on updatesA chain/flowtable update with duplicated devices in the same batch ispossible. Unfortunately, netdev event path only removes the firstdevice that is found, leaving unregistered the hook of the duplicateddevice.Check if a duplicated device exists in the transaction batch, bail outwith EEXIST in such case.WARNING is hit when unregistering the hook: [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150 [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full) [...] [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-66293 Severity: Important CVSS3 score: 7.1

Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.52, an out-of-bounds read vulnerability in libpng's simplified API allows reading up to 1012 bytes beyond the png_sRGB_base[512] array when processing valid palette PNG images with partial transparency and gamma correction. The PNG files that trigger this vulnerability are valid per the PNG specification; the bug is in libpng's internal state management. Upgrade to libpng 1.6.52 or later.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpng16-16 < 1.6.44-160000.3.1 (version in image is 1.6.44-160000.2.2).

CVE-2024-53164 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: fix ordering of qlen adjustmentChanges to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen_before_ a call to said function because otherwise it may fail to notifyparent qdiscs when the child is about to become empty.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38087 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: fix use-after-free in taprio_dev_notifierSince taprio's taprio_dev_notifier() isn't protected by anRCU 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.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38110 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:net/mdiobus: Fix potential out-of-bounds clause 45 read/write accessWhen using publicly available tools like 'mdio-tools' to read/write datafrom/to network interface and its PHY via C45 (clause 45) mdiobus,there is no verification of parameters passed to the ioctl andit 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-boundsread/write.Fix that by adding address verification before C45 read/write operation.While this excludes this access from any statistics, it improves security ofread/write operation.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38111 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:net/mdiobus: Fix potential out-of-bounds read/write accessWhen using publicly available tools like 'mdio-tools' to read/write datafrom/to network interface and its PHY via mdiobus, there is no verification ofparameters 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-boundsread/write.Fix that by adding address verification before read/write operation.While this excludes this access from any statistics, it improves security ofread/write operation.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38118 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_completeThis reworks MGMT_OP_REMOVE_ADV_MONITOR to not use mgmt_pending_add toavoid crashes like bellow:==================================================================BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406Read of size 8 at addr ffff88801c53f318 by task kworker/u5:5/5341CPU: 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/2014Workqueue: hci0 hci_cmd_sync_workCall Trace: 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 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/0x7fFreed 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38129 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: Fix use-after-free in page_pool_recycle_in_ringsyzbot reported a uaf in page_pool_recycle_in_ring:BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __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 pagepool from being free before all pages have been recycled.recycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is notenabled, which will trigger Wempty-body build warning. Add definitionfor pool stat macro to fix warning.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38159 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: fix the 'para' buffer size to avoid reading out of boundsSet the size to 6 instead of 2, since 'para' array is passed to'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads5 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.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38177 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:sch_hfsc: make hfsc_qlen_notify() idempotenthfsc_qlen_notify() is not idempotent either and not friendlyto its callers, like fq_codel_dequeue(). Let's make it idempotentto ease qdisc_tree_reduce_backlog() callers' life:1. update_vf() decreases cl->cl_nactive, so we can check whether it isnon-zero before calling it.2. eltree_remove() always removes RB node cl->el_node, but we can use RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38323 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:net: atm: add lec_mutexsyzbot found its way in net/atm/lec.c, and found an error pathin 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:1008Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142CPU: 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/2025Call Trace: __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 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/0x7fFreed 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38352 Severity: Important CVSS3 score: 7.0

Description: 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() andcalls handle_posix_cpu_timers() from IRQ, it can be reaped by its parentor debugger right after unlock_task_sighand().If a concurrent posix_cpu_timer_del() runs at that moment, it won't beable to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/orlock_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, becauseexit_task_work() is called before exit_notify(). But the check stillmakes sense, task_work_add(&tsk->posix_cputimers_work.work) will failanyway in this case.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38375 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:virtio-net: ensure the received length does not exceed allocated sizeIn xdp_linearize_page, when reading the following buffers from the ring,we forget to check the received length with the true allocate size. Thiscan lead to an out-of-bound read. This commit adds that missing check.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38380 Severity: Important CVSS3 score: 7.0

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38477 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix race condition on qfq_aggregateA race condition can occur when 'agg' is modified in qfq_change_agg(called during qfq_enqueue) while other threads access itconcurrently. For example, qfq_dump_class may trigger a NULLdereference, 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 andqfq_dump_class_stats.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38485 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flushfxls8962af_fifo_flush() uses indio_dev->active_scan_mask (withiio_for_each_active_channel()) without making sure the indio_devstays in buffer mode.There is a race if indio_dev exits buffer mode in the middle of theinterrupt that flushes the fifo. Fix this by callingsynchronize_irq() to ensure that no interrupt is currently running whendisabling buffer mode.Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read[...]_find_first_bit_le from fxls8962af_fifo_flush+0x17c/0x290fxls8962af_fifo_flush from fxls8962af_interrupt+0x80/0x178fxls8962af_interrupt from irq_thread_fn+0x1c/0x7cirq_thread_fn from irq_thread+0x110/0x1f4irq_thread from kthread+0xe0/0xfckthread from ret_from_fork+0x14/0x2c

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38500 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: interface: fix use-after-free after changing collect_md xfrm interfacecollect_md property on xfrm interfaces can only be set on device creation,thus xfrmi_changelink() should fail when called on such interfaces.The check to enforce this was done only in the case where the xi wasreturned from xfrmi_locate() which doesn't look for the collect_mdinterface, and thus the validation was never reached.Calling changelink would thus errornously place the special interface xiin the xfrmi_net->xfrmi hash, but since it also exists in thexfrmi_net->collect_md_xfrmi pointer it would lead to a double free whenthe net namespace was taken down [1].Change the check to use the xi from netdev_priv which is available earlierin the function to prevent changes in xfrm collect_md interfaces.[1] resulting oops:[ 8.516540] kernel BUG at net/core/dev.c:12029![ 8.516552] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 8.516559] CPU: 0 UID: 0 PID: 12 Comm: kworker/u80:0 Not tainted 6.15.0-virtme #5 PREEMPT(voluntary)[ 8.516565] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 8.516569] Workqueue: netns cleanup_net[ 8.516579] RIP: 0010:unregister_netdevice_many_notify+0x101/0xab0[ 8.516590] Code: 90 0f 0b 90 48 8b b0 78 01 00 00 48 8b 90 80 01 00 00 48 89 56 08 48 89 32 4c 89 80 78 01 00 00 48 89 b8 80 01 00 00 eb ac 90 <0f> 0b 48 8b 45 00 4c 8d a0 88 fe ff ff 48 39 c5 74 5c 41 80 bc 24[ 8.516593] RSP: 0018:ffffa93b8006bd30 EFLAGS: 00010206[ 8.516598] RAX: ffff98fe4226e000 RBX: ffffa93b8006bd58 RCX: ffffa93b8006bc60[ 8.516601] RDX: 0000000000000004 RSI: 0000000000000000 RDI: dead000000000122[ 8.516603] RBP: ffffa93b8006bdd8 R08: dead000000000100 R09: ffff98fe4133c100[ 8.516605] R10: 0000000000000000 R11: 00000000000003d2 R12: ffffa93b8006be00[ 8.516608] R13: ffffffff96c1a510 R14: ffffffff96c1a510 R15: ffffa93b8006be00[ 8.516615] FS: 0000000000000000(0000) GS:ffff98fee73b7000(0000) knlGS:0000000000000000[ 8.516619] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 8.516622] CR2: 00007fcd2abd0700 CR3: 000000003aa40000 CR4: 0000000000752ef0[ 8.516625] PKRU: 55555554[ 8.516627] Call Trace:[ 8.516632] [ 8.516635] ? rtnl_is_locked+0x15/0x20[ 8.516641] ? unregister_netdevice_queue+0x29/0xf0[ 8.516650] ops_undo_list+0x1f2/0x220[ 8.516659] cleanup_net+0x1ad/0x2e0[ 8.516664] process_one_work+0x160/0x380[ 8.516673] worker_thread+0x2aa/0x3c0[ 8.516679] ? __pfx_worker_thread+0x10/0x10[ 8.516686] kthread+0xfb/0x200[ 8.516690] ? __pfx_kthread+0x10/0x10[ 8.516693] ? __pfx_kthread+0x10/0x10[ 8.516697] ret_from_fork+0x82/0xf0[ 8.516705] ? __pfx_kthread+0x10/0x10[ 8.516709] ret_from_fork_asm+0x1a/0x30[ 8.516718]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38554 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got droppedBy inducing delays in the right places, Jann Horn created a reproducer fora hard to hit UAF issue that became possible after VMAs were allowed to berecycled by adding SLAB_TYPESAFE_BY_RCU to their cache.Race description is borrowed from Jann's discovery report:lock_vma_under_rcu() looks up a VMA locklessly with mas_walk() underrcu_read_lock(). At that point, the VMA may be concurrently freed, and itcan be recycled by another process. vma_start_read() then increments thevma->vm_refcnt (if it is in an acceptable range), and if this succeeds,vma_start_read() can return a recycled VMA.In this scenario where the VMA has been recycled, lock_vma_under_rcu()will then detect the mismatching ->vm_mm pointer and drop the VMA throughvma_end_read(), which calls vma_refcount_put(). vma_refcount_put() dropsthe refcount and then calls rcuwait_wake_up() using a copy of vma->vm_mm. This is wrong: It implicitly assumes that the caller is keeping the VMA'smm alive, but in this scenario the caller has no relation to the VMA's mm,so the rcuwait_wake_up() can cause UAF.The diagram depicting the race:T1 T2 T3== == ==lock_vma_under_rcu mas_walk mmap vma_start_read __refcount_inc_not_zero_limited_acquire munmap __vma_enter_locked refcount_add_not_zero vma_end_read vma_refcount_put __refcount_dec_and_test rcuwait_wait_event rcuwait_wake_up [UAF]Note that rcuwait_wait_event() in T3 does not block because refcount wasalready dropped by T1. At this point T3 can exit and free the mm causingUAF in T1.To avoid this we move vma->vm_mm verification into vma_start_read() andgrab vma->vm_mm to stabilize it before vma_refcount_put() operation.[surenb@google.com: v3]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38588 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: prevent infinite loop in rt6_nlmsg_size()While testing prior patch, I was able to triggeran infinite loop in rt6_nlmsg_size() in the following place:list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, fib6_siblings) { rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len);}This is because fib6_del_route() and fib6_add_rt2node()uses list_del_rcu(), which can confuse rcu readers,because they might no longer see the head of the list.Restart the loop if f6i->fib6_nsiblings is zero.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38617 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:net/packet: fix a race in packet_set_ring() and packet_notifier()When packet_set_ring() releases po->bind_lock, another thread canrun packet_notifier() and process an NETDEV_UP event.This race and the fix are both similar to that of commit 15fe076edea7("net/packet: fix a race in packet_bind() and packet_notifier()").There too the packet_notifier NETDEV_UP event managed to run while apo->bind_lock critical section had to be temporarily released. Andthe fix was similarly to temporarily set po->num to zero to keepthe socket unhooked until the lock is retaken.The po->bind_lock in packet_set_ring and packet_notifier precede theintroduction of git history.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38618 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Do not allow binding to VMADDR_PORT_ANYIt is possible for a vsock to autobind to VMADDR_PORT_ANY. This cancause a use-after-free when a connection is made to the bound socket.The socket returned by accept() also has port VMADDR_PORT_ANY but is noton the list of unbound sockets. Binding it will result in an extrarefcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keepthe binding until socket destruction).Modify the check in __vsock_bind_connectible() to also prevent bindingto VMADDR_PORT_ANY.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38644 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject TDLS operations when station is not associatedsyzbot triggered a WARN in ieee80211_tdls_oper() by sendingNL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT,before association completed and without prior TDLS setup.This left internal state like sdata->u.mgd.tdls_peer uninitialized,leading to a WARN_ON() in code paths that assumed it was valid.Reject the operation early if not in station mode or not associated.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38664 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix a null pointer dereference in ice_copy_and_init_pkg()Add check for the return value of devm_kmemdup()to prevent potential null pointer dereference.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38685 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix vmalloc out-of-bounds write in fast_imageblitThis issue triggers when a userspace program does an ioctlFBIOPUT_CON2FBMAP by passing console number and frame buffer number.Ideally this maps console to frame buffer and updates the screen ifconsole is visible.As part of mapping it has to do resize of console according to framebuffer info. if this resize fails and returns from vc_do_resize() andcontinues further. At this point console and new frame buffer are mappedand sets display vars. Despite failure still it continue to proceedupdating the screen at later stages where vc_data is related to previousframe buffer and frame buffer info and display vars are mapped to newframe buffer and eventully leading to out-of-bounds write infast_imageblit(). This bheviour is excepted only when fg_console isequal to requested console which is a visible console and updates screenwith invalid struct references in fbcon_putcs().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38703 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: Make dma-fences compliant with the safe access rulesXe can free some of the data pointed to by the dma-fences it exports. Mostnotably the timeline name can get freed if userspace closes the associatedsubmit queue. At the same time the fence could have been exported to athird party (for example a sync_fence fd) which will then cause an use-after-free on subsequent access.To make this safe we need to make the driver compliant with the newlydocumented dma-fence rules. Driver has to ensure a RCU grace periodbetween signalling a fence and freeing any data pointed to by said fence.For the timeline name we simply make the queue be freed via kfree_rcu andfor the shared lock associated with multiple queues we add a RCU graceperiod before freeing the per GT structure holding the lock.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38710 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Validate i_depth for exhash directoriesA fuzzer test introduced corruption that ends up with a depth of 0 indir_e_read(), causing an undefined shift by 32 at: index = hash >> (32 - dip->i_depth);As calculated in an open-coded way in dir_make_exhash(), the minimumdepth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 isinvalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time.So we can avoid the undefined behaviour by checking for depth valueslower than the minimum in gfs2_dinode_in(). Values greater than themaximum are already being checked for there.Also switch the calculation in dir_make_exhash() to use ilog2() toclarify how the depth is calculated.Tested with the syzkaller repro.c and xfstests '-g quick'.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38737 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix oops due to uninitialised variableFix smb3_init_transform_rq() to initialise buffer to NULL before callingnetfs_alloc_folioq_buffer() as netfs assumes it can append to the buffer itis given. Setting it to NULL means it should start a fresh buffer, but thevalue is currently undefined.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39682 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:tls: fix handling of zero-length records on the rx_listEach recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA recordIf the next record has different type than what has already beenprocessed we break out of the main processing loop. If the recordhas already been decrypted (which may be the case for TLS 1.3 wherewe don't know type until decryption) we queue the pending recordto the rx_list. Next recvmsg() will pick it up from there.Queuing the skb to rx_list after zero-copy decrypt is not possible,since in that case we decrypted directly to the user space buffer,and we don't have an skb to queue (darg.skb points to the ciphertextskb for access to metadata like length).Only data records are allowed zero-copy, and we break the processingloop after each non-data record. So we should never zero-copy andthen find out that the record type has changed. The corner casewe missed is when the initial record comes from rx_list, and it'szero length.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39742 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()The function divides number of online CPUs by num_core_siblings, andlater checks the divider by zero. This implies a possibility to getand divide-by-zero runtime error. Fix it by moving the check prior todivision. This also helps to save one indentation level.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39750 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Correct tid cleanup when tid setup failsCurrently, if any error occurs during ath12k_dp_rx_peer_tid_setup(),the tid value is already incremented, even though the correspondingTID is not actually allocated. Proceed toath12k_dp_rx_peer_tid_delete() starting from unallocated tid,which might leads to freeing unallocated TID and cause potentialcrash or out-of-bounds access.Hence, fix by correctly decrementing tid before cleanup to match onlythe successfully allocated TIDs.Also, remove tid-- from failure case of ath12k_dp_rx_peer_frag_setup(),as decrementing the tid before cleanup in loop will take care of this.Compile tested only.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39761 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Decrement TID on RX peer frag setup error handlingCurrently, TID is not decremented before peer cleanup, during errorhandling path of ath12k_dp_rx_peer_frag_setup(). This could lead toout-of-bounds access in peer->rx_tid[].Hence, add a decrement operation for TID, before peer cleanup toensures proper cleanup and prevents out-of-bounds access issues whenthe RX peer frag setup fails.Found during code review. Compile tested only.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39826 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:net: rose: convert 'use' field to refcount_tThe 'use' field in struct rose_neigh is used as a reference counter butlacks atomicity. This can lead to race conditions where a rose_neighstructure is freed while still being referenced by other code paths.For example, when rose_neigh->use becomes zero during an ioctl operationvia rose_rt_ioctl(), the structure may be removed while its timer isstill active, potentially causing use-after-free issues.This patch changes the type of 'use' from unsigned short to refcount_t andupdates all code paths to use rose_neigh_hold() and rose_neigh_put() whichoperate reference counts atomically.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39896 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Prevent recovery work from being queued during device removalUse disable_work_sync() instead of cancel_work_sync() in ivpu_dev_fini()to ensure that no new recovery work items can be queued after deviceremoval has started. Previously, recovery work could be scheduled evenafter canceling existing work, potentially leading to use-after-freebugs if recovery accessed freed resources.Rename ivpu_pm_cancel_recovery() to ivpu_pm_disable_recovery() to betterreflect its new behavior.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39963 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix incorrect io_kiocb reference in io_link_skbIn io_link_skb function, there is a bug where prev_notif is incorrectlyassigned using 'nd' instead of 'prev_nd'. This causes the contextvalidation check to compare the current notification with itself insteadof comparing it with the previous notification.Fix by using the correct prev_nd parameter when obtaining prev_notif.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39973 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: add validation for ring_len paramThe `ring_len` parameter provided by the virtual function (VF)is assigned directly to the hardware memory context (HMC) withoutany validation.To address this, introduce an upper boundary check for both Tx and Rxqueue lengths. The maximum number of descriptors supported by thehardware is 8k-32.Additionally, enforce alignment constraints: Tx rings must be a multipleof 8, and Rx rings must be a multiple of 32.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39977 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:futex: Prevent use-after-free during requeue-PIsyzbot managed to trigger the following race: T1 T2 futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() /* preempt */ * timeout/ signal wakes T1 * futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage /* back */ wake_up_state(q->task, TASK_NORMAL);In this scenario futex_wait_requeue_pi() is able to leave without usingfutex_q::lock_ptr for synchronization.This can be prevented by reading futex_q::task before updating thefutex_q::requeue_state. A reference on the task_struct is not neededbecause requeue_pi_wake_futex() is invoked with a spinlock_t held whichimplies a RCU read section.Even if T1 terminates immediately after, the task_struct will remain validduring T2's wake_up_state(). A READ_ONCE on futex_q::task beforefutex_requeue_pi_complete() is enough because it ensures that the variableis read before the state is updated.Read futex_q::task before updating the requeue state, use it for thefollowing wakeup.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39981 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Fix possible UAFsThis attemps to fix possible UAFs caused by struct mgmt_pending beingfreed while still being processed like in the following trace, in orderto fix mgmt_pending_valid is introduce and use to check if themgmt_pending hasn't been removed from the pending list, on the completecallbacks it is used to check and in addtion remove the cmd from the listwhile holding mgmt_pending_lock to avoid TOCTOU problems since if the cmdis left on the list it can still be accessed and freed.BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223Read of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55CPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci0 hci_cmd_sync_workCall Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 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 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245 Allocated by task 12210: 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:4364 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247 add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364 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:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 sock_write_iter+0x258/0x330 net/socket.c:1133 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 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/0x7fFreed by task 12221: 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:2381 [inline] slab_free mm/slub.c:4648 [inline] kfree+0x18e/0x440 mm/slub.c:4847 mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444 hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290 hci_dev_do_close net/bluetooth/hci_core.c:501 [inline] hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526 sock_do_ioctl+0xd9/0x300 net/socket.c:1192 sock_ioctl+0x576/0x790 net/socket.c:1313 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+0xf---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40018 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: Defer ip_vs_ftp unregister during netns cleanupOn the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftpbefore connections with valid cp->app pointers are flushed, leading to ause-after-free.Fix this by introducing a global `exiting_module` flag, set to true inip_vs_ftp_exit() before unregistering the pernet subsystem. In__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netnscleanup (when exiting_module is false) and defer it to__ip_vs_cleanup_batch(), which unregisters all apps after all connectionsare flushed. If called during module exit, unregister ip_vs_ftpimmediately.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40019 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essiv_aead_crypt so thatit's also checked for decryption and in-place encryption.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40130 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Fix data race in CPU latency PM QoS request handlingThe cpu_latency_qos_add/remove/update_request interfaces lack internalsynchronization by design, requiring the caller to ensure thread safety.The current implementation relies on the 'pm_qos_enabled' flag, which isinsufficient to prevent concurrent access and cannot serve as a propersynchronization mechanism. This has led to data races and listcorruption issues.A typical race condition call trace is:[Thread A]ufshcd_pm_qos_exit() --> cpu_latency_qos_remove_request() --> cpu_latency_qos_apply(); --> pm_qos_update_target() --> plist_del <--(1) delete plist node --> memset(req, 0, sizeof(*req)); --> hba->pm_qos_enabled = false;[Thread B]ufshcd_devfreq_target --> ufshcd_devfreq_scale --> ufshcd_scale_clks --> ufshcd_pm_qos_update <--(2) pm_qos_enabled is true --> cpu_latency_qos_update_request --> pm_qos_update_target --> plist_del <--(3) plist node use-after-freeIntroduces a dedicated mutex to serialize PM QoS operations, preventingdata races and ensuring safe access to PM QoS resources, including sysfsinterface reads.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40159 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Harden userspace-supplied xdp_desc validationTurned out certain clearly invalid values passed in xdp_desc fromuserspace can pass xp_{,un}aligned_validate_desc() and then leadto UBs or just invalid frames to be queued for xmit.desc->len close to ``U32_MAX`` with a non-zero pool->tx_metadata_lencan cause positive integer overflow and wraparound, the same way lowenough desc->addr with a non-zero pool->tx_metadata_len can causenegative integer overflow. Both scenarios can then pass thevalidation successfully.This doesn't happen with valid XSk applications, but can be usedto perform attacks.Always promote desc->len to ``u64`` first to exclude positiveoverflows of it. Use explicit check_{add,sub}_overflow() whenvalidating desc->addr (which is ``u64`` already).bloat-o-meter reports a little growth of the code size:add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44)Function old new deltaxskq_cons_peek_desc 299 330 +31xsk_tx_peek_release_desc_batch 973 1002 +29xsk_generic_xmit 3148 3132 -16but hopefully this doesn't hurt the performance much.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40176 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:tls: wait for pending async decryptions if tls_strp_msg_hold failsAsync decryption calls tls_strp_msg_hold to create a clone of theinput skb to hold references to the memory it uses. If we fail toallocate that clone, proceeding with async decryption can lead tovarious issues (UAF on the skb, writing into userspace memory afterthe recv() call has returned).In this case, wait for all pending decryption requests.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40186 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request().syzbot reported the splat below in tcp_conn_request(). [0]If a listener is close()d while a TFO socket is being processed intcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk->skand calls inet_child_forget(), which calls tcp_disconnect() for theTFO socket.After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(),where reqsk_put() is called due to !reqsk->sk.Then, reqsk_fastopen_remove() in tcp_conn_request() decrements thelast req->rsk_refcnt and frees reqsk, and __reqsk_free() at thedrop_and_free label causes the refcount underflow for the listenerand double-free of the reqsk.Let's remove reqsk_fastopen_remove() in tcp_conn_request().Note that other callers make sure tp->fastopen_rsk is not NULL.[0]:refcount_t: underflow; use-after-free.WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28)Modules linked in:CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025RIP: 0010:refcount_warn_saturate (lib/refcount.c:28)Code: ab e8 8e b4 98 ff 0f 0b c3 cc cc cc cc cc 80 3d a4 e4 d6 01 00 75 9c c6 05 9b e4 d6 01 01 48 c7 c7 e8 df fb ab e8 6a b4 98 ff <0f> 0b e9 03 5b 76 00 cc 80 3d 7d e4 d6 01 00 0f 85 74 ff ff ff c6RSP: 0018:ffffa79fc0304a98 EFLAGS: 00010246RAX: d83af4db1c6b3900 RBX: ffff9f65c7a69020 RCX: d83af4db1c6b3900RDX: 0000000000000000 RSI: 00000000ffff7fff RDI: ffffffffac78a280RBP: 000000009d781b60 R08: 0000000000007fff R09: ffffffffac6ca280R10: 0000000000017ffd R11: 0000000000000004 R12: ffff9f65c7b4f100R13: ffff9f65c7d23c00 R14: ffff9f65c7d26000 R15: ffff9f65c7a64ef8FS: 00007f9f962176c0(0000) GS:ffff9f65fcf00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000200000000180 CR3: 000000000dbbe006 CR4: 0000000000372ef0Call Trace: tcp_conn_request (./include/linux/refcount.h:400 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301) tcp_rcv_state_process (net/ipv4/tcp_input.c:6708) tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670) tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1906) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:438) ip6_input (net/ipv6/ip6_input.c:500) ipv6_rcv (net/ipv6/ip6_input.c:311) __netif_receive_skb (net/core/dev.c:6104) process_backlog (net/core/dev.c:6456) __napi_poll (net/core/dev.c:7506) net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40212 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix refcount leak in nfsd_set_fh_dentry()nfsd exports a "pseudo root filesystem" which is used by NFSv4 to findthe various exported filesystems using LOOKUP requests from a known rootfilehandle. NFSv3 uses the MOUNT protocol to find those exportedfilesystems and so is not given access to the pseudo root filesystem.If a v3 (or v2) client uses a filehandle from that filesystem,nfsd_set_fh_dentry() will report an error, but still stores the exportin "struct svc_fh" even though it also drops the reference (exp_put()).This means that when fh_put() is called an extra reference will be droppedwhich can lead to use-after-free and possible denial of service.Normal NFS usage will not provide a pseudo-root filehandle to a v3client. This bug can only be triggered by the client synthesising anincorrect filehandle.To fix this we move the assignments to the svc_fh later, after allpossible error cases have been detected.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40214 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Initialise scc_index in unix_add_edge().Quang Le reported that the AF_UNIX GC could garbage-collect areceive queue of an alive in-flight socket, with a nice repro.The repro consists of three stages. 1) 1-a. Create a single cyclic reference with many sockets 1-b. close() all sockets 1-c. Trigger GC 2) 2-a. Pass sk-A to an embryo sk-B 2-b. Pass sk-X to sk-X 2-c. Trigger GC 3) 3-a. accept() the embryo sk-B 3-b. Pass sk-B to sk-C 3-c. close() the in-flight sk-A 3-d. Trigger GCAs of 2-c, sk-A and sk-X are linked to unix_unvisited_vertices,and unix_walk_scc() groups them into two different SCCs: unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3Once GC completes, unix_graph_grouped is set to true.Also, unix_graph_maybe_cyclic is set to true due to sk-X'scyclic self-reference, which makes close() trigger GC.At 3-b, unix_add_edge() allocates unix_sk(sk-B)->vertex andlinks it to unix_unvisited_vertices.unix_update_graph() is called at 3-a. and 3-b., but neitherunix_graph_grouped nor unix_graph_maybe_cyclic is changedbecause both sk-B's listener and sk-C are not in-flight.3-c decrements sk-A's file refcnt to 1.Since unix_graph_grouped is true at 3-d, unix_walk_scc_fast()is finally called and iterates 3 sockets sk-A, sk-B, and sk-X: sk-A -> sk-B (-> sk-C) sk-X -> sk-XThis is totally fine. All of them are not yet close()d andshould be grouped into different SCCs.However, unix_vertex_dead() misjudges that sk-A and sk-B arein the same SCC and sk-A is dead. unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index <-- Wrong! && sk-A's file refcnt == unix_sk(sk-A)->vertex->out_degree ^-- 1 in-flight count for sk-B -> sk-A is dead !?The problem is that unix_add_edge() does not initialise scc_index.Stage 1) is used for heap spraying, making a newly allocatedvertex have vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START)set by unix_walk_scc() at 1-c.Let's track the max SCC index from the previous unix_walk_scc()call and assign the max + 1 to a new vertex's scc_index.This way, we can continue to avoid Tarjan's algorithm whilepreventing misjudgments.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40215 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: delete x->tunnel as we delete xThe ipcomp fallback tunnels currently get deleted (from the variouslists and hashtables) as the last user state that needed that fallbackis destroyed (not deleted). If a reference to that user state stillexists, the fallback state will remain on the hashtables/lists,triggering the WARN in xfrm_state_fini. Because of those remainingreferences, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_statesynchronously on net exit path") is not complete.We recently fixed one such situation in TCP due to defered freeing ofskbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as wecurrently drop dst")). This can also happen due to IP reassembly: skbswith a secpath remain on the reassembly queue until netnsdestruction. If we can't guarantee that the queues are flushed by thetime xfrm_state_fini runs, there may still be references to a (user)xfrm_state, preventing the timely deletion of the correspondingfallback state.Instead of chasing each instance of skbs holding a secpath one by one,this patch fixes the issue directly within xfrm, by deleting thefallback state as soon as the last user state depending on it has beendeleted. Destruction will still happen when the final reference isdropped.A separate lockdep class for the fallback state is required sincewe're going to lock x->tunnel while x is locked.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40242 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix unlikely race in gdlm_put_lockIn gdlm_put_lock(), there is a small window of time in which theDFL_UNMOUNT flag has been set but the lockspace hasn't been released,yet. In that window, dlm may still call gdlm_ast() and gdlm_bast().To prevent it from dereferencing freed glock objects, only free theglock if the lockspace has actually been released.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40257 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix a race in mptcp_pm_del_add_timer()mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer)while another might have free entry already, as reported by syzbot.Add RCU protection to fix this issue.Also change confusing add_timer variable with stop_timer boolean.syzbot report:BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)}Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025Workqueue: events mptcp_workerCall Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40258 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix race condition in mptcp_schedule_work()syzbot reported use-after-free in mptcp_schedule_work() [1]Issue here is that mptcp_schedule_work() schedules a work,then gets a refcount on sk->sk_refcnt if the work was scheduled.This refcount will be released by mptcp_worker().[A] if (schedule_work(...)) {[B] sock_hold(sk); return true; }Problem is that mptcp_worker() can run immediately and complete before [B]We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk);[1]refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40280 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free in tipc_mon_reinit_self().syzbot reported use-after-free of tipc_net(net)->monitors[]in tipc_mon_reinit_self(). [0]The array is protected by RTNL, but tipc_mon_reinit_self()iterates over it without RTNL.tipc_mon_reinit_self() is called from tipc_net_finalize(),which is always under RTNL except for tipc_net_finalize_work().Let's hold RTNL in tipc_net_finalize_work().[0]:BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)}Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025Workqueue: events tipc_net_finalize_workCall Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568 kasan_check_byte include/linux/kasan.h:399 [inline] lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline] rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline] rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244 rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243 write_lock_bh include/linux/rwlock_rt.h:99 [inline] tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718 tipc_net_finalize+0x115/0x190 net/tipc/net.c:140 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 6089: 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:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657 tipc_enable_bearer net/tipc/bearer.c:357 [inline] __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047 __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline] tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393 tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline] tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 ____sys_sendmsg+0x508/0x820 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40297 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix use-after-free due to MST port state bypasssyzbot reported[1] a use-after-free when deleting an expired fdb. It isdue to a race condition between learning still happening and a port beingdeleted, after all its fdbs have been flushed. The port's state has beentoggled to disabled so no learning should happen at that time, but if wehave MST enabled, it will bypass the port's state, that together with VLANfiltering disabled can lead to fdb learning at a time when it shouldn'thappen while the port is being deleted. VLAN filtering must be disabledbecause we flush the port VLANs when it's being deleted which will stoplearning. This fix adds a check for the port's vlan group which isinitialized to NULL when the port is getting deleted, that avoids the portstate bypass. When MST is enabled there would be a minimal new overheadin the fast-path because the port's vlan group pointer is cache-hot.[1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40309 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix UAF on sco_conn_freeBUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline]BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline]BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410net/bluetooth/sco.c:107Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: hci13 hci_cmd_sync_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x191/0x550 mm/kasan/report.c:482 kasan_report+0xc4/0x100 mm/kasan/report.c:595 sco_conn_free net/bluetooth/sco.c:87 [inline] kref_put include/linux/kref.h:65 [inline] sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441 hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline] hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313 hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121 hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147 hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689 hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319 worker_thread+0xbee/0x1200 kernel/workqueue.c:3400 kthread+0x3c7/0x870 kernel/kthread.c:463 ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 31370: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4382 [inline] __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xae/0x220 net/core/sock.c:2239 sk_alloc+0x34/0x5a0 net/core/sock.c:2295 bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151 sco_sock_alloc net/bluetooth/sco.c:562 [inline] sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593 bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135 __sock_create+0x3ad/0x780 net/socket.c:1589 sock_create net/socket.c:1647 [inline] __sys_socket_create net/socket.c:1684 [inline] __sys_socket+0xd5/0x330 net/socket.c:1731 __do_sys_socket net/socket.c:1745 [inline] __se_sys_socket net/socket.c:1743 [inline] __x64_sys_socket+0x7a/0x90 net/socket.c:1743 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 31374: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2428 [inline] slab_free mm/slub.c:4701 [inline] kfree+0x199/0x3b0 mm/slub.c:4900 sk_prot_free net/core/sock.c:2278 [inline] __sk_destruct+0x4aa/0x630 net/core/sock.c:2373 sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333 __sock_release net/socket.c:649 [inline] sock_close+0xb8/0x230 net/socket.c:1439 __fput+0x3d1/0x9e0 fs/file_table.c:468 task_work_run+0x206/0x2a0 kernel/task_work.c:227 get_signal+0x1201/0x1410 kernel/signal.c:2807 arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] s---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40362 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix multifs mds auth caps issueThe mds auth caps check should also validate thefsname along with the associated caps. Not doingso would result in applying the mds auth caps ofone fs on to the other fs in a multifs ceph cluster.The bug causes multiple issues w.r.t userauthentication, following is one such example.Steps to Reproduce (on vstart cluster):1. Create two file systems in a cluster, say 'fsname1' and 'fsname2'2. Authorize read only permission to the user 'client.usr' on fs 'fsname1' $ceph fs authorize fsname1 client.usr / r3. Authorize read and write permission to the same user 'client.usr' on fs 'fsname2' $ceph fs authorize fsname2 client.usr / rw4. Update the keyring $ceph auth get client.usr >> ./keyringWith above permssions for the user 'client.usr', following is theexpectation. a. The 'client.usr' should be able to only read the contents and not allowed to create or delete files on file system 'fsname1'. b. The 'client.usr' should be able to read/write on file system 'fsname2'.But, with this bug, the 'client.usr' is allowed to read/write on filesystem 'fsname1'. See below.5. Mount the file system 'fsname1' with the user 'client.usr' $sudo bin/mount.ceph usr@.fsname1=/ /kmnt_fsname1_usr/6. Try creating a file on file system 'fsname1' with user 'client.usr'. This should fail but passes with this bug. $touch /kmnt_fsname1_usr/file17. Mount the file system 'fsname1' with the user 'client.admin' and create a file. $sudo bin/mount.ceph admin@.fsname1=/ /kmnt_fsname1_admin $echo "data" > /kmnt_fsname1_admin/admin_file18. Try removing an existing file on file system 'fsname1' with the user 'client.usr'. This shoudn't succeed but succeeds with the bug. $rm -f /kmnt_fsname1_usr/admin_file1For more information, please take a look at the corresponding mds/fuse patchand tests added by looking into the tracker mentioned below.v2: Fix a possible null dereference in doutcv3: Don't store fsname from mdsmap, validate against ceph_mount_options's fsname and use itv4: Code refactor, better warning message and fix possible compiler warning[ Slava.Dubeyko: "fsname check failed" -> "fsname mismatch" ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-54874 Severity: Important CVSS3 score: 7.0

Description: OpenJPEG is an open-source JPEG 2000 codec. In OpenJPEG from 2.5.1 through 2.5.3, a call to opj_jp2_read_header may lead to OOB heap memory write when the data stream p_stream is too short and p_image is not initialized.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenjp2-7 > 0-0 (version in image is 2.5.3-160000.2.2).

CVE-2025-68223 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: delete radeon_fence_process in is_signaled, no deadlockDelete the attempt to progress the queue when checking if fence issignaled. This avoids deadlock.dma-fence_ops::signaled can be called with the fence lock in unknownstate. For radeon, the fence lock is also the wait queue lock. This cancause a self deadlock when signaled() tries to make forward progress onthe wait queue. But advancing the queue is unneeded because incorrectlyreturning false from signaled() is perfectly acceptable.(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68285 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: fix potential use-after-free in have_mon_and_osd_map()The wait loop in __ceph_open_session() can race with the clientreceiving a new monmap or osdmap shortly after the initial map isreceived. Both ceph_monc_handle_map() and handle_one_map() installa new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap;under client->monc.mutex and client->osdc.lock respectively, butbecause neither is taken in have_mon_and_osd_map() it's possible forclient->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch;condition to dereference an already freed map. This happens to bereproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30Rewrite the wait loop to check the above condition directly withclient->monc.mutex and client->osdc.lock taken as appropriate. Whileat it, improve the timeout handling (previously mount_timeout could beexceeded in case wait_event_interruptible_timeout() slept more thanonce) and access client->auth_err under client->monc.mutex to matchhow it's set in finish_auth().monmap_show() and osdmap_show() now take the respective lock beforeaccessing the map as well.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68324 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: imm: Fix use-after-free bug caused by unfinished delayed workThe delayed work item 'imm_tq' is initialized in imm_attach() andscheduled via imm_queuecommand() for processing SCSI commands. When theIMM parallel port SCSI host adapter is detached through imm_detach(),the imm_struct device instance is deallocated.However, the delayed work might still be pending or executingwhen imm_detach() is called, leading to use-after-free bugswhen the work function imm_interrupt() accesses the alreadyfreed imm_struct memory.The race condition can occur as follows:CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck()imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USEAdd disable_delayed_work_sync() in imm_detach() to guarantee propercancellation of the delayed work item before imm_struct is deallocated.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68732 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:gpu: host1x: Fix race in syncpt alloc/freeFix race condition between host1x_syncpt_alloc()and host1x_syncpt_put() by using kref_put_mutex()instead of kref_put() + manual mutex locking.This ensures no thread can acquire thesyncpt_mutex after the refcount drops to zerobut before syncpt_release acquires it.This prevents races where syncpoints couldbe allocated while still being cleaned upfrom a previous release.Remove explicit mutex locking in syncpt_releaseas kref_put_mutex() handles this atomically.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68735 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Prevent potential UAF in group creationThis commit prevents the possibility of a use after free issue in theGROUP_CREATE ioctl function, which arose as pointer to the group isaccessed in that ioctl function after storing it in the Xarray.A malicious userspace can second guess the handle of a group and tryto call GROUP_DESTROY ioctl from another thread around the same timeas GROUP_CREATE ioctl.To prevent the use after free exploit, this commit uses a mark on anentry of group pool Xarray which is added just before returning fromthe GROUP_CREATE ioctl function. The mark is checked for all ioctlsthat specify the group handle and so userspace won't be abe to deletea group that isn't marked yet.v2: Add R-bs and fixes tags

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68781 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:usb: phy: fsl-usb: Fix use-after-free in delayed work during device removalThe delayed work item otg_event is initialized in fsl_otg_conf() andscheduled under two conditions:1. When a host controller binds to the OTG controller.2. When the USB ID pin state changes (cable insertion/removal).A race condition occurs when the device is removed via fsl_otg_remove():the fsl_otg instance may be freed while the delayed work is still pendingor executing. This leads to use-after-free when the work functionfsl_otg_event() accesses the already freed memory.The problematic scenario:(detach thread) | (delayed work)fsl_otg_remove() | kfree(fsl_otg_dev) //FREE| fsl_otg_event() | og = container_of(...) //USE | og-> //USEFix this by calling disable_delayed_work_sync() in fsl_otg_remove()before deallocating the fsl_otg structure. This ensures the delayed workis properly canceled and completes execution prior to memory deallocation.This bug was identified through static analysis.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71089 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:iommu: disable SVA when CONFIG_X86 is setPatch series "Fix stale IOTLB entries for kernel address space", v7.This proposes a fix for a security vulnerability related to IOMMU SharedVirtual Addressing (SVA). In an SVA context, an IOMMU can cache kernelpage table entries. When a kernel page table page is freed andreallocated for another purpose, the IOMMU might still hold stale,incorrect entries. This can be exploited to cause a use-after-free orwrite-after-free condition, potentially leading to privilege escalation ordata corruption.This solution introduces a deferred freeing mechanism for kernel pagetable pages, which provides a safe window to notify the IOMMU toinvalidate its caches before the page is reused.This patch (of 8):In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardwareshares and walks the CPU's page tables. The x86 architecture maps thekernel's virtual address space into the upper portion of every process'spage table. Consequently, in an SVA context, the IOMMU hardware can walkand cache kernel page table entries.The Linux kernel currently lacks a notification mechanism for kernel pagetable changes, specifically when page table pages are freed and reused. The IOMMU driver is only notified of changes to user virtual addressmappings. This can cause the IOMMU's internal caches to retain staleentries for kernel VA.Use-After-Free (UAF) and Write-After-Free (WAF) conditions arise whenkernel page table pages are freed and later reallocated. The IOMMU couldmisinterpret the new data as valid page table entries. The IOMMU mightthen walk into attacker-controlled memory, leading to arbitrary physicalmemory DMA access or privilege escalation. This is also aWrite-After-Free issue, as the IOMMU will potentially continue to writeAccessed and Dirty bits to the freed memory while attempting to walk thestale page tables.Currently, SVA contexts are unprivileged and cannot access kernelmappings. However, the IOMMU will still walk kernel-only page tables allthe way down to the leaf entries, where it realizes the mapping is for thekernel and errors out. This means the IOMMU still caches theseintermediate page table entries, making the described vulnerability a realconcern.Disable SVA on x86 architecture until the IOMMU can receive notificationto flush the paging cache before freeing the CPU kernel page table pages.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71112 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: add VLAN id validation before usingCurrently, the VLAN id may be used without validation whenreceive a VLAN configuration mailbox from VF. The length ofvlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may causeout-of-bounds memory access once the VLAN id is bigger thanor equal to VLAN_N_VID.Therefore, VLAN id needs to be checked to ensure it is withinthe range of VLAN_N_VID.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71128 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:erspan: Initialize options_len before referencing options.The struct ip_tunnel_info has a flexible array member namedoptions that is protected by a counted_by(options_len)attribute.The compiler will use this information to enforce runtime boundschecking deployed by FORTIFY_SOURCE string helpers.As laid out in the GCC documentation, the counter must beinitialized before the first reference to the flexible arraymember.After scanning through the files that use struct ip_tunnel_infoand also refer to options or options_len, it appears the normalcase is to use the ip_tunnel_info_opts_set() helper.Said helper would initialize options_len properly before copyingdata into options, however in the GRE ERSPAN code a partialupdate is done, preventing the use of the helper function.Before this change the handling of ERSPAN traffic in GRE tunnelswould cause a kernel panic when the kernel is compiled withGCC 15+ and having FORTIFY_SOURCE configured:memcpy: detected buffer overflow: 4 byte write of buffer size 0Call Trace: __fortify_panic+0xd/0xf erspan_rcv.cold+0x68/0x83 ? ip_route_input_slow+0x816/0x9d0 gre_rcv+0x1b2/0x1c0 gre_rcv+0x8e/0x100 ? raw_v4_input+0x2a0/0x2b0 ip_protocol_deliver_rcu+0x1ea/0x210 ip_local_deliver_finish+0x86/0x110 ip_local_deliver+0x65/0x110 ? ip_rcv_finish_core+0xd6/0x360 ip_rcv+0x186/0x1a0Reported-at: https://launchpad.net/bugs/2129580

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-0775 Severity: Important CVSS3 score: 7.0

Description: npm cli Incorrect Permission Assignment Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of npm cli. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.The specific flaw exists within the handling of modules. The application loads modules from an unsecured location. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of a target user. Was ZDI-CAN-25430.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
cockpit > 0-0 (version in image is 340-160000.3.2).

CVE-2026-22999 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: do not free existing class in qfq_change_class()Fixes qfq_change_class() error case.cl->qdisc and cl should only be freed if a new class and qdiscwere allocated, or we risk various UAF.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23001 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:macvlan: fix possible UAF in macvlan_forward_source()Add RCU protection on (struct macvlan_source_entry)->vlan.Whenever macvlan_hash_del_source() is called, we must clearentry->vlan pointer before RCU grace period starts.This allows macvlan_forward_source() to skip overentries queued for freeing.Note that macvlan_dev are already RCU protected, as theyare embedded in a standard netdev (netdev_priv(ndev)).https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23066 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix recvmsg() unconditional requeueIf rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call atthe front of the recvmsg queue already has its mutex locked, it requeuesthe call - whether or not the call is already queued. The call may be onthe queue because MSG_PEEK was also passed and so the call was not dequeuedor because the I/O thread requeued it.The unconditional requeue may then corrupt the recvmsg queue, leading tothings like UAFs or refcount underruns.Fix this by only requeuing the call if it isn't already on the queue - andmoving it to the front if it is already queued. If we don't queue it, wehave to put the ref we obtained by dequeuing it.Also, MSG_PEEK doesn't dequeue the call so shouldn't callrxrpc_notify_socket() for the call if we didn't use up all the data on thequeue, so fix that also.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-49940 Severity: Moderate CVSS3 score: 6.8

Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: prevent possible tunnel refcount underflowWhen a session is created, it sets a backpointer to its tunnel. Whenthe session refcount drops to 0, l2tp_session_free drops the tunnelrefcount if session->tunnel is non-NULL. However, session->tunnel isset in l2tp_session_create, before the tunnel refcount is incrementedby l2tp_session_register, which leaves a small window wheresession->tunnel is non-NULL when the tunnel refcount hasn't beenbumped.Moving the assignment to l2tp_session_register is trivial butl2tp_session_create calls l2tp_session_set_header_len which usessession->tunnel to get the tunnel's encap. Add an encap arg tol2tp_session_set_header_len to avoid using session->tunnel.If l2tpv3 sessions have colliding IDs, it is possible forl2tp_v3_session_get to race with l2tp_session_register and fetch asession which doesn't yet have session->tunnel set. Add a check forthis case.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-15444 Severity: Moderate CVSS3 score: 6.8

Description: Crypt::Sodium::XS module versions prior to 0.000042, for Perl, include a vulnerable version of libsodiumlibsodium <= 1.0.20 or a version of libsodium released before December 30, 2025 contains a vulnerability documented as CVE-2025-69277 https://www.cve.org/CVERecord?id=CVE-2025-69277 .The libsodium vulnerability states:In atypical use cases involving certain custom cryptography or untrusted data to crypto_core_ed25519_is_valid_point, mishandles checks for whether an elliptic curve point is valid because it sometimes allows points that aren't in the main cryptographic group.0.000042 includes a version of libsodium updated to 1.0.20-stable, released January 3, 2026, which includes a fix for the vulnerability.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libsodium26 > 0-0 (version in image is 1.0.20-160000.2.2).

CVE-2025-38106 Severity: Moderate CVSS3 score: 6.8

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix use-after-free of sq->thread in __io_uring_show_fdinfo()syzbot reports:BUG: KASAN: slab-use-after-free in getrusage+0x1109/0x1a60Read of size 8 at addr ffff88810de2d2c8 by task a.out/304CPU: 0 UID: 0 PID: 304 Comm: a.out Not tainted 6.16.0-rc1 #1 PREEMPT(voluntary)Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xd0/0x670 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? getrusage+0x1109/0x1a60 kasan_report+0xce/0x100 ? getrusage+0x1109/0x1a60 getrusage+0x1109/0x1a60 ? __pfx_getrusage+0x10/0x10 __io_uring_show_fdinfo+0x9fe/0x1790 ? ksys_read+0xf7/0x1c0 ? do_syscall_64+0xa4/0x260 ? vsnprintf+0x591/0x1100 ? __pfx___io_uring_show_fdinfo+0x10/0x10 ? __pfx_vsnprintf+0x10/0x10 ? mutex_trylock+0xcf/0x130 ? __pfx_mutex_trylock+0x10/0x10 ? __pfx_show_fd_locks+0x10/0x10 ? io_uring_show_fdinfo+0x57/0x80 io_uring_show_fdinfo+0x57/0x80 seq_show+0x38c/0x690 seq_read_iter+0x3f7/0x1180 ? inode_set_ctime_current+0x160/0x4b0 seq_read+0x271/0x3e0 ? __pfx_seq_read+0x10/0x10 ? __pfx__raw_spin_lock+0x10/0x10 ? __mark_inode_dirty+0x402/0x810 ? selinux_file_permission+0x368/0x500 ? file_update_time+0x10f/0x160 vfs_read+0x177/0xa40 ? __pfx___handle_mm_fault+0x10/0x10 ? __pfx_vfs_read+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? fdget_pos+0x24d/0x4b0 ksys_read+0xf7/0x1c0 ? __pfx_ksys_read+0x10/0x10 ? do_user_addr_fault+0x43b/0x9c0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f0f74170fc9Code: 00 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 73 01 c3 48 8b 8RSP: 002b:00007fffece049e8 EFLAGS: 00000206 ORIG_RAX: 0000000000000000RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0f74170fc9RDX: 0000000000001000 RSI: 00007fffece049f0 RDI: 0000000000000004RBP: 00007fffece05ad0 R08: 0000000000000000 R09: 00007fffece04d90R10: 0000000000000000 R11: 0000000000000206 R12: 00005651720a1100R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 298: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_node_noprof+0xe8/0x330 copy_process+0x376/0x5e00 create_io_thread+0xab/0xf0 io_sq_offload_create+0x9ed/0xf20 io_uring_setup+0x12b0/0x1cc0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 22: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0xc4/0x360 rcu_core+0x5ff/0x19f0 handle_softirqs+0x18c/0x530 run_ksoftirqd+0x20/0x30 smpboot_thread_fn+0x287/0x6c0 kthread+0x30d/0x630 ret_from_fork+0xef/0x1a0 ret_from_fork_asm+0x1a/0x30Last potentially related work creation: kasan_save_stack+0x33/0x60 kasan_record_aux_stack+0x8c/0xa0 __call_rcu_common.constprop.0+0x68/0x940 __schedule+0xff2/0x2930 __cond_resched+0x4c/0x80 mutex_lock+0x5c/0xe0 io_uring_del_tctx_node+0xe1/0x2b0 io_uring_clean_tctx+0xb7/0x160 io_uring_cancel_generic+0x34e/0x760 do_exit+0x240/0x2350 do_group_exit+0xab/0x220 __x64_sys_exit_group+0x39/0x40 x64_sys_call+0x1243/0x1840 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe buggy address belongs to the object at ffff88810de2cb00 which belongs to the cache task_struct of size 3712The buggy address is located 1992 bytes inside of freed 3712-byte region [ffff88810de2cb00, ffff88810de2d980)which is caused by the task_struct pointed to by sq->thread beingreleased while it is being used in the function__io_uring_show_fdinfo(). Holding ctx->uring_lock does not prevent ehrerelase or exit of sq->thread.Fix this by assigning and looking up ->thread under RCU, and grabbing areference to the task_struct. This e---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40345 Severity: Moderate CVSS3 score: 6.8

Description: In the Linux kernel, the following vulnerability has been resolved:usb: storage: sddr55: Reject out-of-bound new_pbaDiscovered by Atuin - Automated Vulnerability Discovery Engine.new_pba comes from the status packet returned after each write.A bogus device could report values beyond the block count derivedfrom info->capacity, letting the driver walk off the end ofpba_to_lba[] and corrupt heap memory.Reject PBAs that exceed the computed block count and fail thetransfer so we avoid touching out-of-range mapping entries.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-6069 Severity: Moderate CVSS3 score: 6.8

Description: The html.parser.HTMLParser class had worse-case quadratic complexity when processing certain crafted malformed inputs potentially leading to amplified denial-of-service.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpython3_13-1_0 < 3.13.11-160000.1.1 (version in image is 3.13.5-160000.2.2).

CVE-2025-64505 Severity: Moderate CVSS3 score: 6.8

Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to version 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_do_quantize function when processing PNG files with malformed palette indices. The vulnerability occurs when palette_lookup array bounds are not validated against externally-supplied image data, allowing an attacker to craft a PNG file with out-of-range palette indices that trigger out-of-bounds memory access. This issue has been patched in version 1.6.51.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpng16-16 < 1.6.44-160000.3.1 (version in image is 1.6.44-160000.2.2).

CVE-2025-64506 Severity: Moderate CVSS3 score: 6.8

Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_write_image_8bit function when processing 8-bit images through the simplified write API with convert_to_8bit enabled. The vulnerability affects 8-bit grayscale+alpha, RGB/RGBA, and images with incomplete row data. A conditional guard incorrectly allows 8-bit input to enter code expecting 16-bit input, causing reads up to 2 bytes beyond allocated buffer boundaries. This issue has been patched in version 1.6.51.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpng16-16 < 1.6.44-160000.3.1 (version in image is 1.6.44-160000.2.2).

CVE-2025-64720 Severity: Moderate CVSS3 score: 6.8

Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, an out-of-bounds read vulnerability exists in png_image_read_composite when processing palette images with PNG_FLAG_OPTIMIZE_ALPHA enabled. The palette compositing code in png_init_read_transformations incorrectly applies background compositing during premultiplication, violating the invariant component ≤ alpha x 257 required by the simplified PNG API. This issue has been patched in version 1.6.51.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpng16-16 < 1.6.44-160000.3.1 (version in image is 1.6.44-160000.2.2).

CVE-2025-65018 Severity: Moderate CVSS3 score: 6.8

Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, there is a heap buffer overflow vulnerability in the libpng simplified API function png_image_finish_read when processing 16-bit interlaced PNGs with 8-bit output format. Attacker-crafted interlaced PNG files cause heap writes beyond allocated buffer bounds. This issue has been patched in version 1.6.51.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpng16-16 < 1.6.44-160000.3.1 (version in image is 1.6.44-160000.2.2).

CVE-2026-22801 Severity: Moderate CVSS3 score: 6.8

Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.26 to 1.6.53, there is an integer truncation in the libpng simplified write API functions png_write_image_16bit and png_write_image_8bit causes heap buffer over-read when the caller provides a negative row stride (for bottom-up image layouts) or a stride exceeding 65535 bytes. The bug was introduced in libpng 1.6.26 (October 2016) by casts added to silence compiler warnings on 16-bit systems. This vulnerability is fixed in 1.6.54.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpng16-16 < 1.6.44-160000.4.1 (version in image is 1.6.44-160000.2.2).

CVE-2024-36883 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix out-of-bounds access in ops_initnet_alloc_generic is called by net_alloc, which is called without anylocking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. Itis read twice, first to allocate an array, then to set s.len, which islater used to limit the bounds of the array access.It is possible that the array is allocated and another thread isregistering a new pernet ops, increments max_gen_ptrs, which is then usedto set s.len with a larger than allocated length for the variable array.Fix it by reading max_gen_ptrs only once in net_alloc_generic. Ifmax_gen_ptrs is later incremented, it will be caught in net_assign_generic.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-15366 Severity: Moderate CVSS3 score: 6.7

Description: The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313 > 0-0 (version in image is 3.13.5-160000.2.2).

CVE-2025-15367 Severity: Moderate CVSS3 score: 6.7

Description: The poplib module, when passed a user-controlled command, can haveadditional commands injected using newlines. Mitigation rejects commandscontaining control characters.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313 > 0-0 (version in image is 3.13.5-160000.2.2).

CVE-2025-38088 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmapmemtrace mmap issue has an out of bounds issue. This patch fixes the bychecking that the requested mapping region size should stay within theallocated region size.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38213 Severity: Moderate CVSS3 score: 6.7

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38289 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Avoid potential ndlp use-after-free in dev_loss_tmo_callbkSmatch detected a potential use-after-free of an ndlp oject indev_loss_tmo_callbk during driver unload or fatal error handling.Fix by reordering code to avoid potential use-after-free if initialnodelist reference has been previously removed.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38573 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:spi: cs42l43: Property entry should be a null-terminated arrayThe software node does not specify a count of property entries, so thearray must be null-terminated.When unterminated, this can lead to a fault in the downstream cs35l56amplifier driver, because the node parse walks off the end of thearray into unknown memory.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40364 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix io_req_prep_async with provided buffersio_req_prep_async() can import provided buffers, commit the ring stateby giving up on that before, it'll be reimported later if needed.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68743 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:mshv: Fix create memory region overlap checkThe current check is incorrect; it only checks if the beginning or endof a region is within an existing region. This doesn't account foruserspace specifying a region that begins before and ends after anexisting region.Change the logic to a range intersection check against gfns and uaddrsfor each region.Remove mshv_partition_region_by_uaddr() as it is no longer used.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68801 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_router: Fix neighbour use-after-freeWe sometimes observe use-after-free when dereferencing a neighbour [1].The problem seems to be that the driver stores a pointer to theneighbour, but without holding a reference on it. A reference is onlytaken when the neighbour is used by a nexthop.Fix by simplifying the reference counting scheme. Always take areference when storing a neighbour pointer in a neighbour entry. Avoidtaking a referencing when the neighbour is used by a nexthop as theneighbour entry associated with the nexthop already holds a reference.Tested by running the test that uncovered the problem over 300 times.Without this patch the problem was reproduced after a handful ofiterations.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310Read of size 8 at addr ffff88817f8e3420 by task ip/3929CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023Call Trace: dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6e/0x300 print_report+0xfc/0x1fb kasan_report+0xe4/0x110 mlxsw_sp_neigh_entry_update+0x2d4/0x310 mlxsw_sp_router_rif_gone_sync+0x35f/0x510 mlxsw_sp_rif_destroy+0x1ea/0x730 mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0 __mlxsw_sp_inetaddr_lag_event+0xcc/0x130 __mlxsw_sp_inetaddr_event+0xf5/0x3c0 mlxsw_sp_router_netdevice_event+0x1015/0x1580 notifier_call_chain+0xcc/0x150 call_netdevice_notifiers_info+0x7e/0x100 __netdev_upper_dev_unlink+0x10b/0x210 netdev_upper_dev_unlink+0x79/0xa0 vrf_del_slave+0x18/0x50 do_set_master+0x146/0x7d0 do_setlink.isra.0+0x9a0/0x2880 rtnl_newlink+0x637/0xb20 rtnetlink_rcv_msg+0x6fe/0xb90 netlink_rcv_skb+0x123/0x380 netlink_unicast+0x4a3/0x770 netlink_sendmsg+0x75b/0xc90 __sock_sendmsg+0xbe/0x160 ____sys_sendmsg+0x5b2/0x7d0 ___sys_sendmsg+0xfd/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53[...]Allocated by task 109: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x2c1/0x790 neigh_alloc+0x6af/0x8f0 ___neigh_create+0x63/0xe90 mlxsw_sp_nexthop_neigh_init+0x430/0x7e0 mlxsw_sp_nexthop_type_init+0x212/0x960 mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280 mlxsw_sp_nexthop6_group_get+0x392/0x6a0 mlxsw_sp_fib6_entry_create+0x46a/0xfd0 mlxsw_sp_router_fib6_replace+0x1ed/0x5f0 mlxsw_sp_router_fib6_event_work+0x10a/0x2a0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20Freed by task 154: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free_bulk.part.0+0x1eb/0x5e0 kvfree_rcu_bulk+0x1f2/0x260 kfree_rcu_work+0x130/0x1b0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20Last potentially related work creation: kasan_save_stack+0x30/0x50 kasan_record_aux_stack+0x8c/0xa0 kvfree_call_rcu+0x93/0x5b0 mlxsw_sp_router_neigh_event_work+0x67d/0x860 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-13151 Severity: Moderate CVSS3 score: 6.6

Description: Stack-based buffer overflow in libtasn1 version: v4.20.0. The function fails to validate the size of input data resulting in a buffer overflow in asn1_expend_octet_string.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libtasn1-6 > 0-0 (version in image is 4.20.0-160000.3.2).

CVE-2025-38085 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast racehuge_pmd_unshare() drops a reference on a page table that may havepreviously been shared across processes, potentially turning it into anormal page table used in another process in which unrelated VMAs canafterwards be installed.If this happens in the middle of a concurrent gup_fast(), gup_fast() couldend up walking the page tables of another process. While I don't see anyway in which that immediately leads to kernel memory corruption, it isreally 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 THPcollapse.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38142 Severity: Moderate CVSS3 score: 6.6

Description: 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 sensoris not found.find_ec_sensor_index() may return a negative value (e.g. -ENOENT),but its result was used without checking, which could lead toundefined 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]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38161 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix error flow upon firmware failure for RQ destructionUpon RQ destruction if the firmware command fails which is thelast resource to be destroyed some SW resources were already cleanedregardless 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 theobject 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/0x148Modules 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 #1Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : refcount_warn_saturate+0xf4/0x148lr : refcount_warn_saturate+0xf4/0x148sp : ffff80008b81b7e0x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37fx14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fffx5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600Call 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38172 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: avoid using multiple devices with different typeFor multiple devices, both primary and extra devices should be thesame type. `erofs_init_device` has already guaranteed that if theprimary is a file-backed device, extra devices should also beregular files.However, if the primary is a block device while the extra deviceis a file-backed device, `erofs_init_device` will get an ENOTBLK,which is not treated as an error in `erofs_fc_get_tree`, and thatleads to an UAF: erofs_fc_get_tree get_tree_bdev_flags(erofs_fc_fill_super) erofs_read_superblock erofs_init_device // sbi->dif0 is not inited yet, // return -ENOTBLK deactivate_locked_super free(sbi) if (err is -ENOTBLK) sbi->dif0.file = filp_open() // sbi UAFSo if -ENOTBLK is hitted in `erofs_init_device`, it means theprimary device must be a block device, and the extra deviceis not a block device. The error can be converted to -EINVAL.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38209 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: remove tag set when second admin queue config failsCommit 104d0e2f6222 ("nvme-fabrics: reset admin connection for secureconcatenation") modified nvme_tcp_setup_ctrl() to callnvme_tcp_configure_admin_queue() twice. The first call prepares forDH-CHAP negotitation, and the second call is required for secureconcatenation. However, this change triggered BUG KASAN slab-use-after-free in blk_mq_queue_tag_busy_iter(). This BUG can be recreated byrepeating the blktests test case nvme/063 a few times [1].When the BUG happens, nvme_tcp_create_ctrl() fails in the call chainbelow:nvme_tcp_create_ctrl() nvme_tcp_alloc_ctrl() new=true ... Alloc nvme_tcp_ctrl and admin_tag_set nvme_tcp_setup_ctrl() new=true nvme_tcp_configure_admin_queue() new=true ... Succeed nvme_alloc_admin_tag_set() ... Alloc the tag set for admin_tag_set nvme_stop_keep_alive() nvme_tcp_teardown_admin_queue() remove=false nvme_tcp_configure_admin_queue() new=false nvme_tcp_alloc_admin_queue() ... Fail, but do not call nvme_remove_admin_tag_set() nvme_uninit_ctrl() nvme_put_ctrl() ... Free up the nvme_tcp_ctrl and admin_tag_setThe first call of nvme_tcp_configure_admin_queue() succeeds withnew=true argument. The second call fails with new=false argument. Thissecond call does not call nvme_remove_admin_tag_set() on failure, due tothe new=false argument. Then the admin tag set is not removed. However,nvme_tcp_create_ctrl() assumes that nvme_tcp_setup_ctrl() would callnvme_remove_admin_tag_set(). Then it frees up struct nvme_tcp_ctrl whichhas admin_tag_set field. Later on, the timeout handler accesses theadmin_tag_set field and causes the BUG KASAN slab-use-after-free.To not leave the admin tag set, call nvme_remove_admin_tag_set() whenthe second nvme_tcp_configure_admin_queue() call fails. Do not returnfrom nvme_tcp_setup_ctrl() on failure. Instead, jump to "destroy_admin"go-to label to call nvme_tcp_teardown_admin_queue() which callsnvme_remove_admin_tag_set().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38277 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: nand: ecc-mxic: Fix use of uninitialized variable retIf ctx->steps is zero, the loop processing ECC steps is skipped,and the variable ret remains uninitialized. It is later checkedand returned, which leads to undefined behavior and may causeunpredictable results in user space or kernel crashes.This scenario can be triggered in edge cases such as misconfiguredgeometry, ECC engine misuse, or if ctx->steps is not validatedafter initialization.Initialize ret to zero before the loop to ensure correct and safebehavior regardless of the ctx->steps value.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38315 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btintel: Check dsbr size from EFI variableSince the size of struct btintel_dsbr is already known, we can juststart there instead of querying the EFI variable size. If the finalresult doesn't match what we expect also fail. This fixes a stack bufferoverflow when the EFI variable is larger than struct btintel_dsbr.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38395 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:regulator: gpio: Fix the out-of-bounds access to drvdata::gpiodsdrvdata::gpiods is supposed to hold an array of 'gpio_desc' pointers. Butthe memory is allocated for only one pointer. This will lead toout-of-bounds access later in the code if 'config::ngpios' is > 1. Sofix the code to allocate enough memory to hold 'config::ngpios' of GPIOdescriptors.While at it, also move the check for memory allocation failure to be belowthe allocation to make it more readable.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38408 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:genirq/irq_sim: Initialize work context pointers properlyInitialize `ops` member's pointers properly by using kzalloc() instead ofkmalloc() when allocating the simulation work context. Otherwise thepointers contain random content leading to invalid dereferencing.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38449 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:drm/gem: Acquire references on GEM handles for framebuffersA GEM handle can be released while the GEM buffer object is attachedto a DRM framebuffer. This leads to the release of the dma-buf backingthe buffer object, if any. [1] Trying to use the framebuffer in furthermode-setting operations leads to a segmentation fault. Most easilyhappens with driver that use shadow planes for vmap-ing the dma-bufduring 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] [ 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 preventsthis from happening. The framebuffer's cleanup later puts the handlereferences.Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM objectinstance") triggers the segmentation fault easily by using the dma-buffield more widely. The underlying issue with reference counting hasbeen 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38455 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flightReject migration of SEV{-ES} state if either the source or destination VMis actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in thesection between incrementing created_vcpus and online_vcpus. The bulk ofvCPU creation runs _outside_ of kvm->lock to allow creating multiple vCPUsin parallel, and so sev_info.es_active can get toggled from false=>true inthe destination VM after (or during) svm_vcpu_create(), resulting in anSEV{-ES} VM effectively having a non-SEV{-ES} vCPU.The issue manifests most visibly as a crash when trying to free a vCPU'sNULL 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: 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 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 crashingthe 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 abogus VMSA page. Accessing P---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38466 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:perf: Revert to requiring CAP_SYS_ADMIN for uprobesJann reports that uprobes can be used destructively when used in themiddle of an instruction. The kernel only verifies there is a validinstruction at the requested offset, but due to variable instructionlength cannot determine if this is an instruction as seen by theintended execution stream.Additionally, Mark Rutland notes that on architectures that mix datain the text segment (like arm64), a similar things can be done if thedata word is 'mistaken' for an instruction.As such, require CAP_SYS_ADMIN for uprobes.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38556 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: Harden s32ton() against conversion to 0 bitsTesting by the syzbot fuzzer showed that the HID core gets ashift-out-of-bounds exception when it tries to convert a 32-bitquantity to a 0-bit quantity. Ideally this should never occur, butthere are buggy devices and some might have a report field with sizeset to zero; we shouldn't reject the report or the device just becauseof that.Instead, harden the s32ton() routine so that it returns a reasonableresult instead of crashing when it is called with the number of bitsset to 0 -- the same as what snto32() does.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38574 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:pptp: ensure minimal skb length in pptp_xmit()Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb dataon ppp_sync_txmung") fixed ppp_sync_txmunge()We need a similar fix in pptp_xmit(), otherwise we mightread uninit data as reported by syzbot.BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x893/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38604 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: Kill URBs before clearing tx status queueIn rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearingb_tx_status.queue. This change prevents callbacks from using already freedskb due to anchor was not killed before freeing such skb. BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211] Call Trace: rtl8187_tx_cb+0x116/0x150 [rtl8187] __usb_hcd_giveback_urb+0x9d/0x120 usb_giveback_urb_bh+0xbb/0x140 process_one_work+0x19b/0x3c0 bh_worker+0x1a7/0x210 tasklet_action+0x10/0x30 handle_softirqs+0xf0/0x340 __irq_exit_rcu+0xcd/0xf0 common_interrupt+0x85/0xa0 Tested on RTL8187BvE device.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38628 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:vdpa/mlx5: Fix release of uninitialized resources on error pathThe commit in the fixes tag made sure that mlx5_vdpa_free()is the single entrypoint for removing the vdpa device resourcesadded in mlx5_vdpa_dev_add(), even in the cleanup path ofmlx5_vdpa_dev_add().This means that all functions from mlx5_vdpa_free() should be able tohandle uninitialized resources. This was not the case though:mlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx()were not able to do so. This caused the splat below when addinga vdpa device without a MAC address.This patch fixes these remaining issues:- Makes mlx5_vdpa_destroy_mr_resources() return early if called on uninitialized resources.- Moves mlx5_cmd_init_async_ctx() early on during device addition because it can't fail. This means that mlx5_cmd_cleanup_async_ctx() also can't fail. To mirror this, move the call site of mlx5_cmd_cleanup_async_ctx() in mlx5_vdpa_free().An additional comment was added in mlx5_vdpa_free() to documentthe expectations of functions called from this context.Splat: mlx5_core 0000:b5:03.2: mlx5_vdpa_dev_add:3950:(pid 2306) warning: No mac address provisioned? ------------[ cut here ]------------ WARNING: CPU: 13 PID: 2306 at kernel/workqueue.c:4207 __flush_work+0x9a/0xb0 [...] Call Trace: ? __try_to_del_timer_sync+0x61/0x90 ? __timer_delete_sync+0x2b/0x40 mlx5_vdpa_destroy_mr_resources+0x1c/0x40 [mlx5_vdpa] mlx5_vdpa_free+0x45/0x160 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x327/0x890 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x2c1/0x4d0 [vdpa] genl_family_rcv_msg_doit+0xd8/0x130 genl_family_rcv_msg+0x14b/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] genl_rcv_msg+0x47/0xa0 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x27b/0x3b0 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x1fa/0x210 ? ___pte_offset_map+0x17/0x160 ? next_uptodate_folio+0x85/0x2b0 ? percpu_counter_add_batch+0x51/0x90 ? filemap_map_pages+0x515/0x660 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x7b/0x2c0 ? do_read_fault+0x108/0x220 ? do_pte_missing+0x14a/0x3e0 ? __handle_mm_fault+0x321/0x730 ? count_memcg_events+0x13f/0x180 ? handle_mm_fault+0x1fb/0x2d0 ? do_user_addr_fault+0x20c/0x700 ? syscall_exit_work+0x104/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0c25b0feca [...] ---[ end trace 0000000000000000 ]---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38653 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.alCheck pde->proc_ops->proc_lseek directly may cause UAF in rmmod scenario. It's a gap in proc_reg_open() after commit 654b33ada4ab("proc: fix UAF inproc_get_inode()"). Followed by AI Viro's suggestion, fix it in samemanner.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39897 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:net: xilinx: axienet: Add error handling for RX metadata pointer retrievalAdd proper error checking for dmaengine_desc_get_metadata_ptr() whichcan return an error pointer and lead to potential crashes or undefinedbehaviour if the pointer retrieval fails.Properly handle the error by unmapping DMA buffer, freeing the skb andreturning early to prevent further processing with invalid data.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39922 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ixgbe: fix incorrect map used in eee linkmodeincorrectly used ixgbe_lp_map in loops intended to populate thesupported and advertised EEE linkmode bitmaps based on ixgbe_ls_map.This results in incorrect bit setting and potential out-of-boundsaccess, since ixgbe_lp_map and ixgbe_ls_map have different sizesand purposes.ixgbe_lp_map[i] -> ixgbe_ls_map[i]Use ixgbe_ls_map for supported and advertised linkmodes, and keepixgbe_lp_map usage only for link partner (lp_advertised) mapping.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39952 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wilc1000: avoid buffer overflow in WID string configurationFix the following copy overflow warning identified by Smatch checker. drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)This patch introduces size check before accessing the memory buffer.The checks are base on the WID type of received data from the firmware.For WID string configuration, the size limit is determined by individualelement size in 'struct wilc_cfg_str_vals' that is maintained in 'len' fieldof 'struct wilc_cfg_str'.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39965 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: xfrm_alloc_spi shouldn't use 0 as SPIx->id.spi == 0 means "no SPI assigned", but since commit94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create statesand add them to the byspi list with this value.__xfrm_state_delete doesn't remove those states from the byspi list,since they shouldn't be there, and this shows up as a UAF the nexttime we go through the byspi list.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39971 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix idx validation in config queues msgEnsure idx is within range of active/initialized TCs when iterating overvf->ch[idx] in i40e_vc_config_queues_msg().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40219 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOVBefore disabling SR-IOV via config space accesses to the parent PF,sriov_disable() first removes the PCI devices representing the VFs.Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()")such removal operations are serialized against concurrent remove andrescan using the pci_rescan_remove_lock. No such locking was ever addedin sriov_disable() however. In particular when commit 18f9e9d150fc("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI deviceremoval into sriov_del_vfs() there was still no locking around thepci_iov_remove_virtfn() calls.On s390 the lack of serialization in sriov_disable() may cause doubleremove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 0000000000000001 0000000000000000 0000000000000000 0000000180692828 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2.This is because in addition to sriov_disable() removing the VFs, theplatform also generates hot-unplug events for the VFs. This being thereverse operation to the hotplug events generated by sriov_enable() andhandled via pdev->no_vf_scan. And while the event processing takespci_rescan_remove_lock and checks whether the struct pci_dev still exists,the lack of synchronization makes this checking racy.Other races may also be possible of course though given that this lack oflocking persisted so long observable races seem very rare. Even on s390 thelist corruption was only observed with certain devices since the platformevents are only triggered by config accesses after the removal, so as longas the removal finished synchronously they would not race. Either way thelocking is missing so fix this by adding it to the sriov_del_vfs() helper.Just like PCI rescan-remove, locking is also missing in sriov_add_vfs()including for the error case where pci_stop_and_remove_bus_device() iscalled without the PCI rescan-remove lock being held. Even in the non-errorcase, adding new PCI devices and buses should be serialized via the PCIrescan-remove lock. Add the necessary locking.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40266 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Check the untrusted offset in FF-A memory shareVerify the offset to prevent OOB access in the hypervisorFF-A buffer in case an untrusted large enough value[U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX]is set from the host kernel.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40283 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAFThere is a KASAN: slab-use-after-free read in btusb_disconnect().Calling "usb_driver_release_interface(&btusb_driver, data->intf)" willfree the btusb data associated with the interface. The same data isthen used later in the function, hence the UAF.Fix by moving the accesses to btusb data to before the data is free'd.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68340 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:team: Move team device type change at the end of team_port_addAttempting to add a port device that is already up will expectedly fail,but not before modifying the team device header_ops.In the case of the syzbot reproducer the gre0 device isalready in state UP when it attempts to add it as aport device of team0, this fails but before thatheader_ops->create of team0 is changed from eth_header to ipgre_headerin the call to team_dev_type_check_change.Later when we end up in ipgre_header() struct ip_tunnel* points to nonsenseas the private data of the device still holds a struct team.Example sequence of iproute2 commands to reproduce the hang/BUG():ip link add dev team0 type teamip link add dev gre0 type greip link set dev gre0 upip link set dev gre0 master team0ip link set dev team0 upping -I team0 1.1.1.1Move team_dev_type_check_change down where all other checks have passedas it changes the dev type with no way to restore it in caseone of the checks that follow it fail.Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from devThis is done by adding a conditional before the call to dev_set_mtuto prevent it from assigning port_dev->mtu = dev->mtu and insteadletting team_dev_type_check_change assign dev->mtu = port_dev->mtu.The conditional is needed because the patch moves the call toteam_dev_type_check_change past dev_set_mtu.Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68344 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: wavefront: Fix integer overflow in sample size validationThe wavefront_send_sample() function has an integer overflow issuewhen validating sample size. The header->size field is u32 but getscast to int for comparison with dev->freememFix by using unsigned comparison to avoid integer overflow.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68750 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:usb: potential integer overflow in usbg_make_tpg()The variable tpgt in usbg_make_tpg() is defined as unsigned long and isassigned to tpgt->tport_tpgt, which is defined as u16. This may cause aninteger overflow when tpgt is greater than USHRT_MAX (65535). Ihaven't tried to trigger it myself, but it is possible to trigger itby calling usbg_make_tpg() with a large value for tpgt.I modified the type of tpgt to match tpgt->tport_tpgt and adjusted therelevant code accordingly.This patch is similar to commit 59c816c1f24d ("vhost/scsi: potentialmemory corruption").

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68766 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()If irq_domain_translate_twocell() sets "hwirq" to >= MCHP_EIC_NIRQ (2) thenit results in an out of bounds access.The code checks for invalid values, but doesn't set the error code. Return-EINVAL in that case, instead of returning success.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2026-23003 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()Blamed commit did not take care of VLAN encapsulationsas spotted by syzbot [1].Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull().[1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729 __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1 ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500 ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:318 [inline] ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core net/core/dev.c:6139 [inline] __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252 netif_receive_skb_internal net/core/dev.c:6338 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6397 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4960 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586 __alloc_skb+0x805/0x1040 net/core/skbuff.c:690 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712 sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995 tun_alloc_skb drivers/net/tun.c:1461 [inline] tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23057 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: Coalesce only linear skbvsock/virtio common tries to coalesce buffers in rx queue: if a linear skb(with a spare tail room) is followed by a small skb (length limited byGOOD_COPY_LEN = 128), an attempt is made to join them.Since the introduction of MSG_ZEROCOPY support, assumption that a small skbwill always be linear is incorrect. In the zerocopy case, data is lost andthe linear skb is appended with uninitialized kernel memory.Of all 3 supported virtio-based transports, only loopback-transport isaffected. G2H virtio-transport rx queue operates on explicitly linear skbs;see virtio_vsock_alloc_linear_skb() in virtio_vsock_rx_fill(). H2Gvhost-transport may allocate non-linear skbs, but only for sizes that arenot considered for coalescence; see PAGE_ALLOC_COSTLY_ORDER invirtio_vsock_alloc_skb().Ensure only linear skbs are coalesced. Note that skb_tailroom(last_skb) > 0guarantees last_skb is linear.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-7783 Severity: Important CVSS3 score: 6.5

Description: Use of Insufficiently Random Values vulnerability in form-data allows HTTP Parameter Pollution (HPP). This vulnerability is associated with program files lib/form_data.Js.This issue affects form-data: < 2.5.4, 3.0.0 - 3.0.3, 4.0.0 - 4.0.3.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
cockpit > 0-0 (version in image is 340-160000.3.2).

CVE-2023-39328 Severity: Moderate CVSS3 score: 6.5

Description: A vulnerability was found in OpenJPEG similar to CVE-2019-6988. This flaw allows an attacker to bypass existing protections and cause an application crash through a maliciously crafted file.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenjp2-7 > 0-0 (version in image is 2.5.3-160000.2.2).

CVE-2023-40403 Severity: Moderate CVSS3 score: 6.5

Description: The issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.6, tvOS 17, iOS 16.7 and iPadOS 16.7, macOS Monterey 12.7, watchOS 10, iOS 17 and iPadOS 17, macOS Sonoma 14. Processing web content may disclose sensitive information.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libexslt0 > 0-0 (version in image is 1.1.43-160000.2.2).

CVE-2025-11563 Severity: Moderate CVSS3 score: 6.5

Description: Unknown.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
curl < 8.14.1-160000.3.1 (version in image is 8.14.1-160000.2.2).

CVE-2025-13836 Severity: Moderate CVSS3 score: 6.5

Description: When reading an HTTP response from a server, if no read amount is specified, the default behavior will be to use Content-Length. This allows a malicious server to cause the client to read large amounts of data into memory, potentially causing OOM or other DoS.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpython3_13-1_0 < 3.13.11-160000.1.1 (version in image is 3.13.5-160000.2.2).

CVE-2025-14512 Severity: Moderate CVSS3 score: 6.5

Description: A flaw was found in glib. This vulnerability allows a heap buffer overflow and denial-of-service (DoS) via an integer overflow in GLib's GIO (GLib Input/Output) escape_byte_string() function when processing malicious file or remote filesystem attribute values.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
glib2-tools < 2.84.4-160000.1.1 (version in image is 2.84.3-160000.2.2).

CVE-2025-15282 Severity: Moderate CVSS3 score: 6.5

Description: User-controlled data URLs parsed by urllib.request.DataHandler allow injecting headers through newlines in the data URL mediatype.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313 > 0-0 (version in image is 3.13.5-160000.2.2).

CVE-2025-22872 Severity: Moderate CVSS3 score: 6.5

Description: The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g.

,, etc contexts).

Packages affected:

podman > 0-0 (version in image is 5.4.2-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38146 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: Fix the dead loop of MPLS parseThe unexpected MPLS packet may not end with the bottom label stack.When there are many stacks, The label count value has wrapped around.A dead loop occurs, soft lockup/CPU stuck finally.stack backtrace:UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26index -1 is out of range for type '__be32 [3]'CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-UbuntuHardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021Call Trace: show_stack+0x52/0x5c dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36 __ubsan_handle_out_of_bounds.cold+0x44/0x49 key_extract_l3l4+0x82a/0x840 [openvswitch] ? kfree_skbmem+0x52/0xa0 key_extract+0x9c/0x2b0 [openvswitch] ovs_flow_key_extract+0x124/0x350 [openvswitch] ovs_vport_receive+0x61/0xd0 [openvswitch] ? kernel_init_free_pages.part.0+0x4a/0x70 ? get_page_from_freelist+0x353/0x540 netdev_port_receive+0xc4/0x180 [openvswitch] ? netdev_port_receive+0x180/0x180 [openvswitch] netdev_frame_hook+0x1f/0x40 [openvswitch] __netif_receive_skb_core.constprop.0+0x23a/0xf00 __netif_receive_skb_list_core+0xfa/0x240 netif_receive_skb_list_internal+0x18e/0x2a0 napi_complete_done+0x7a/0x1c0 bnxt_poll+0x155/0x1c0 [bnxt_en] __napi_poll+0x30/0x180 net_rx_action+0x126/0x280 ? bnxt_msix+0x67/0x80 [bnxt_en] handle_softirqs+0xda/0x2d0 irq_exit_rcu+0x96/0xc0 common_interrupt+0x8e/0xa0

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38224 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: kvaser_pciefd: refine error prone echo_skb_max handling logicecho_skb_max should define the supported upper limit of echo_skb[]allocated inside the netdevice's priv. The corresponding size valueprovided by this driver to alloc_candev() is KVASER_PCIEFD_CAN_TX_MAX_COUNTwhich is 17.But later echo_skb_max is rounded up to the nearest power of two (for themax case, that would be 32) and the tx/ack indices calculated furtherduring tx/rx may exceed the upper array boundary. Kasan reported this forthe ack case inside kvaser_pciefd_handle_ack_packet(), though the xmitfunction has actually caught the same thing earlier. BUG: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528 Read of size 8 at addr ffff888105e4f078 by task swapper/4/0 CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary) Call Trace: dump_stack_lvl lib/dump_stack.c:122 print_report mm/kasan/report.c:521 kasan_report mm/kasan/report.c:634 kvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528 kvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605 kvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656 kvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684 kvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733 __handle_irq_event_percpu kernel/irq/handle.c:158 handle_irq_event kernel/irq/handle.c:210 handle_edge_irq kernel/irq/chip.c:833 __common_interrupt arch/x86/kernel/irq.c:296 common_interrupt arch/x86/kernel/irq.c:286 Tx max count definitely matters for kvaser_pciefd_tx_avail(), but for seqnumbers' generation that's not the case - we're free to calculate them aswould be more convenient, not taking tx max count into account. The onlydownside is that the size of echo_skb[] should correspond to the max seqnumber (not tx max count), so in some situations a bit more memory wouldbe consumed than could be.Thus make the size of the underlying echo_skb[] sufficient for the roundedmax tx value.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38343 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7996: drop fragments with multicast or broadcast RAIEEE 802.11 fragmentation can only be applied to unicast frames.Therefore, drop fragments with multicast or broadcast RA. This patchaddresses vulnerabilities such as CVE-2020-26145.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38349 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:eventpoll: don't decrement ep refcount while still holding the ep mutexJann Horn points out that epoll is decrementing the ep refcount and thendoing 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 thecode in question will delay the actual call to "ep_free(ep)" until afterit 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'restill using the mutex.Note that this is true even if that other user is also using the same epmutex: 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 stillaccessing the mutex as part of unlocking it, another user can come inand get the now released mutex and free the data structure while thefirst 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 thelast one, we may then unlock the mutex, another user comes in, drops_their_ reference and releases the 'ep' as it now has no users - allwhile 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'sthe whole _point_ of refcounts: unlike mutexes, they are inherentlyabout object lifetimes).

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39825 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix race with concurrent opens in rename(2)Besides sending the rename request to the server, the rename processalso involves closing any deferred close, waiting for outstanding I/Oto complete as well as marking all existing open handles as deleted toprevent them from deferring closes, which increases the race windowfor potential concurrent opens on the target file.Fix this by unhashing the dentry in advance to prevent any concurrentopens on the target.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40133 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: Use __sk_dst_get() and dst_dev_rcu() in mptcp_active_enable().mptcp_active_enable() is called from subflow_finish_connect(),which is icsk->icsk_af_ops->sk_rx_dst_set() and it's not alwaysunder RCU.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40282 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: 6lowpan: reset link-local header on ipv6 recv pathBluetooth 6lowpan.c netdev has header_ops, so it must set link-localheader for RX skb, otherwise things crash, eg. with AF_PACKET SOCK_RAWAdd missing skb_reset_mac_header() for uncompressed ipv6 RX path.For the compressed one, it is done in lowpan_header_decompress().Log: (BlueZ 6lowpan-tester Client Recv Raw - Success)------kernel BUG at net/core/skbuff.c:212!Call Trace:...packet_rcv (net/packet/af_packet.c:2152)...__local_bh_enable_ip (kernel/softirq.c:407)netif_rx (net/core/dev.c:5648)chan_recv_cb (net/bluetooth/6lowpan.c:294 net/bluetooth/6lowpan.c:359)------

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40300 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/vmscape: Add conditional IBPB mitigationVMSCAPE is a vulnerability that exploits insufficient branch predictorisolation between a guest and a userspace hypervisor (like QEMU). Existingmitigations already protect kernel/KVM from a malicious guest. Userspacecan additionally be protected by flushing the branch predictors after aVMexit.Since it is the userspace that consumes the poisoned branch predictors,conditionally issue an IBPB after a VMexit and before returning touserspace. Workloads that frequently switch between hypervisor anduserspace will incur the most overhead from the new IBPB.This new IBPB is not integrated with the existing IBPB sites. Forinstance, a task can use the existing speculation control prctl() toget an IBPB at context switch time. With this implementation, theIBPB is doubled up: one at context switch and another before runninguserspace.The intent is to integrate and optimize these cases post-embargo.[ dhansen: elaborate on suboptimal IBPB solution ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-58364 Severity: Moderate CVSS3 score: 6.5

Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.12 and earlier, an unsafe deserialization and validation of printer attributes causes null dereference in the libcups library. This is a remote DoS vulnerability available in local subnet in default configurations. It can cause the cups & cups-browsed to crash, on all the machines in local network who are listening for printers (so by default for all regular linux machines). On systems where the vulnerability CVE-2024-47176 (cups-filters 1.x/cups-browsed 2.x vulnerability) was not fixed, and the firewall on the machine does not reject incoming communication to IPP port, and the machine is set to be available to public internet, attack vector "Network" is possible. The current versions of CUPS and cups-browsed projects have the attack vector "Adjacent" in their default configurations. Version 2.4.13 contains a patch for CVE-2025-58364.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
cups-config > 0-0 (version in image is 2.4.11-160000.2.2).

CVE-2025-68468 Severity: Moderate CVSS3 score: 6.5

Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending unsolicited announcements containing CNAME resource records pointing it to resource records with short TTLs. As soon as they expire avahi-daemon crashes.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libavahi-client3 < 0.8-160000.4.1 (version in image is 0.8-160000.2.2).

CVE-2025-68471 Severity: Moderate CVSS3 score: 6.5

Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending 2 unsolicited announcements with CNAME resource records 2 seconds apart.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libavahi-client3 < 0.8-160000.4.1 (version in image is 0.8-160000.2.2).

CVE-2025-69224 Severity: Moderate CVSS3 score: 6.5

Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below of the Python HTTP parser may allow a request smuggling attack with the presence of non-ASCII characters. If a pure Python version of AIOHTTP is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. This issue is fixed in version 3.13.3.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313-aiohttp > 0-0 (version in image is 3.11.16-160000.2.2).

CVE-2025-71096 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctlyThe netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have aLS_NLA_TYPE_DGID attribute, it is invalid if it does not.Use the nl parsing logic properly and call nla_parse_deprecated() to fillthe nlattrs array and then directly index that array to get the data forthe DGID. Just fail if it is NULL.Remove the for loop searching for the nla, and squash the validation andparsing into one function.Fixes an uninitialized read from the stack triggered by userspace if itdoes not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVEquery. BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline] BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 hex_byte_pack include/linux/hex.h:13 [inline] ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509 ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633 pointer+0xc09/0x1bd0 lib/vsprintf.c:2542 vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930 vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279 vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426 vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465 vprintk+0x36/0x50 kernel/printk/printk_safe.c:82 _printk+0x17e/0x1b0 kernel/printk/printk.c:2475 ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline] ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141 rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline] rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x333/0x3d0 net/socket.c:729 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671 __sys_sendmsg+0x1aa/0x300 net/socket.c:2703 __compat_sys_sendmsg net/compat.c:346 [inline] __do_compat_sys_sendmsg net/compat.c:353 [inline] __se_compat_sys_sendmsg net/compat.c:350 [inline] __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350 ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-71104 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timerWhen advancing the target expiration for the guest's APIC timer in periodicmode, set the expiration to "now" if the target expiration is in the past(similar to what is done in update_target_expiration()). Blindly addingthe period to the previous target expiration can result in KVM generatinga practically unbounded number of hrtimer IRQs due to programming anexpired timer over and over. In extreme scenarios, e.g. if userspacepauses/suspends a VM for an extended duration, this can even cause hardlockups in the host.Currently, the bug only affects Intel CPUs when using the hypervisor timer(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,a.k.a. hrtimer, which KVM keeps running even on exits to userspace, theHV timer only runs while the guest is active. As a result, if the vCPUdoes not run for an extended duration, there will be a huge gap betweenthe target expiration and the current time the vCPU resumes running.Because the target expiration is incremented by only one period on eachtimer expiration, this leads to a series of timer expirations occurringrapidly after the vCPU/VM resumes.More critically, when the vCPU first triggers a periodic HV timerexpiration after resuming, advancing the expiration by only one periodwill result in a target expiration in the past. As a result, the deltamay be calculated as a negative value. When the delta is converted intoan absolute value (tscdeadline is an unsigned u64), the resulting valuecan overflow what the HV timer is capable of programming. I.e. the largevalue will exceed the VMX Preemption Timer's maximum bit width ofcpu_preemption_timer_multi + 32, and thus cause KVM to switch from theHV timer to the software timer (hrtimers).After switching to the software timer, periodic timer expiration callbacksmay be executed consecutively within a single clock interrupt handler,because hrtimers honors KVM's request for an expiration in the past andimmediately re-invokes KVM's callback after reprogramming. And becausethe interrupt handler runs with IRQs disabled, restarting KVM's hrtimerover and over until the target expiration is advanced to "now" can resultin a hard lockup.E.g. the following hard lockup was triggered in the host when running aWindows VM (only relevant because it used the APIC timer in periodic mode)after resuming the VM from a long suspend (in the host). NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 Moreover, if the suspend duration of the virtual machine is not long enoughto trigger a hard lockup in this scenario, since commit 98c25ead5eda("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVMwill continue using the software timer until the guest reprograms the APICtimer in some way. Since the periodic timer does not require frequent APICtimer register programming, the guest may continue to use the softwaretimer in ---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71123 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix string copying in parse_apply_sb_mount_options()strscpy_pad() can't be used to copy a non-NUL-term string into a NUL-termstring of possibly bigger size. Commit 0efc5990bca5 ("string.h: Introducememtostr() and memtostr_pad()") provides additional information in thatregard. So if this happens, the following warning is observed:strnlen: detected buffer overflow: 65 byte read of buffer size 64WARNING: CPU: 0 PID: 28655 at lib/string_helpers.c:1032 __fortify_report+0x96/0xc0 lib/string_helpers.c:1032Modules linked in:CPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:__fortify_report+0x96/0xc0 lib/string_helpers.c:1032Call Trace: __fortify_panic+0x1f/0x30 lib/string_helpers.c:1039 strnlen include/linux/fortify-string.h:235 [inline] sized_strscpy include/linux/fortify-string.h:309 [inline] parse_apply_sb_mount_options fs/ext4/super.c:2504 [inline] __ext4_fill_super fs/ext4/super.c:5261 [inline] ext4_fill_super+0x3c35/0xad00 fs/ext4/super.c:5706 get_tree_bdev_flags+0x387/0x620 fs/super.c:1636 vfs_get_tree+0x93/0x380 fs/super.c:1814 do_new_mount fs/namespace.c:3553 [inline] path_mount+0x6ae/0x1f70 fs/namespace.c:3880 do_mount fs/namespace.c:3893 [inline] __do_sys_mount fs/namespace.c:4103 [inline] __se_sys_mount fs/namespace.c:4080 [inline] __x64_sys_mount+0x280/0x300 fs/namespace.c:4080 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x64/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7eSince userspace is expected to provide s_mount_opts field to be at most 63characters long with the ending byte being NUL-term, use a 64-byte bufferwhich matches the size of s_mount_opts, so that strscpy_pad() does its jobproperly. Return with error if the user still managed to provide anon-NUL-term string here.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-8194 Severity: Moderate CVSS3 score: 6.5

Description: There is a defect in the CPython "tarfile" module affecting the "TarFile" extraction and entry enumeration APIs. The tar implementation would process tar archives with negative offsets without error, resulting in an infinite loop and deadlock during the parsing of maliciously crafted tar archives. This vulnerability can be mitigated by including the following patch after importing the "tarfile" module: https://gist.github.com/sethmlarson/1716ac5b82b73dbcbf23ad2eff8b33e1

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpython3_13-1_0 < 3.13.11-160000.1.1 (version in image is 3.13.5-160000.2.2).

CVE-2025-9232 Severity: Moderate CVSS3 score: 6.5

Description: Issue summary: An application using the OpenSSL HTTP client API functions maytrigger an out-of-bounds read if the 'no_proxy' environment variable is set andthe host portion of the authority component of the HTTP URL is an IPv6 address.Impact summary: An out-of-bounds read can trigger a crash which leads toDenial of Service for an application.The OpenSSL HTTP client API functions can be used directly by applicationsbut they are also used by the OCSP client functions and CMP (CertificateManagement Protocol) client implementation in OpenSSL. However the URLs usedby these implementations are unlikely to be controlled by an attacker.In this vulnerable code the out of bounds read can only trigger a crash.Furthermore the vulnerability requires an attacker-controlled URL to bepassed from an application to the OpenSSL function and the user has to havea 'no_proxy' environment variable set. For the aforementioned reasons theissue was assessed as Low severity.The vulnerable code was introduced in the following patch releases:3.0.16, 3.1.8, 3.2.4, 3.3.3, 3.4.0 and 3.5.0.The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by thisissue, as the HTTP client implementation is outside the OpenSSL FIPS moduleboundary.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.4.1 (version in image is 3.5.0-160000.3.2).

CVE-2026-0865 Severity: Moderate CVSS3 score: 6.5

Description: User-controlled header names and values containing newlines can allow injecting HTTP headers.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313 > 0-0 (version in image is 3.13.5-160000.2.2).

CVE-2026-22990 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace overzealous BUG_ON in osdmap_apply_incremental()If the osdmap is (maliciously) corrupted such that the incrementalosdmap epoch is different from what is expected, there is no need toBUG. Instead, just declare the incremental osdmap to be invalid.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23004 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()syzbot was able to crash the kernel in rt6_uncached_list_flush_dev()in an interesting way [1]Crash happens in list_del_init()/INIT_LIST_HEAD() while writinglist->prev, while the prior write on list->next went well.static inline void INIT_LIST_HEAD(struct list_head *list){ WRITE_ONCE(list->next, list); // This went well WRITE_ONCE(list->prev, list); // Crash, @list has been freed.}Issue here is that rt6_uncached_list_del() did not attempt to lockul->lock, as list_empty(&rt->dst.rt_uncached) returnedtrue because the WRITE_ONCE(list->next, list) happened on the other CPU.We might use list_del_init_careful() and list_empty_careful(),or make sure rt6_uncached_list_del() always grabs the spinlockwhenever rt->dst.rt_uncached_list has been set.A similar fix is neeed for IPv4.[1] BUG: KASAN: slab-use-after-free in INIT_LIST_HEAD include/linux/list.h:46 [inline] BUG: KASAN: slab-use-after-free in list_del_init include/linux/list.h:296 [inline] BUG: KASAN: slab-use-after-free in rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline] BUG: KASAN: slab-use-after-free in rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020Write of size 8 at addr ffff8880294cfa78 by task kworker/u8:14/3450CPU: 0 UID: 0 PID: 3450 Comm: kworker/u8:14 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}Tainted: [L]=SOFTLOCKUPHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Workqueue: netns cleanup_netCall Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 INIT_LIST_HEAD include/linux/list.h:46 [inline] list_del_init include/linux/list.h:296 [inline] rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline] rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020 addrconf_ifdown+0x143/0x18a0 net/ipv6/addrconf.c:3853 addrconf_notify+0x1bc/0x1050 net/ipv6/addrconf.c:-1 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2268 [inline] call_netdevice_notifiers net/core/dev.c:2282 [inline] netif_close_many+0x29c/0x410 net/core/dev.c:1785 unregister_netdevice_many_notify+0xb50/0x2330 net/core/dev.c:12353 ops_exit_rtnl_list net/core/net_namespace.c:187 [inline] ops_undo_list+0x3dc/0x990 net/core/net_namespace.c:248 cleanup_net+0x4de/0x7b0 net/core/net_namespace.c:696 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 803: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 unpoison_slab_object mm/kasan/common.c:340 [inline] __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366 kasan_slab_alloc include/linux/kasan.h:253 [inline] slab_post_alloc_hook mm/slub.c:4953 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x18d/0x6c0 mm/slub.c:5270 dst_alloc+0x105/0x170 net/core/dst.c:89 ip6_dst_alloc net/ipv6/route.c:342 [inline] icmp6_dst_alloc+0x75/0x460 net/ipv6/route.c:3333 mld_sendpack+0x683/0xe60 net/ipv6/mcast.c:1844 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-24401 Severity: Moderate CVSS3 score: 6.5

Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In versions 0.9rc2 and below, avahi-daemon can be crashed via a segmentation fault by sending an unsolicited mDNS response containing a recursive CNAME record, where the alias and canonical name point to the same domain (e.g., "h.local" as a CNAME for "h.local"). This causes unbounded recursion in the lookup_handle_cname function, leading to stack exhaustion. The vulnerability affects record browsers where AVAHI_LOOKUP_USE_MULTICAST is set explicitly, which includes record browsers created by resolvers used by nss-mdns. This issue is patched in commit 78eab31128479f06e30beb8c1cbf99dd921e2524.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libavahi-client3 > 0-0 (version in image is 0.8-160000.2.2).

CVE-2026-25210 Severity: Moderate CVSS3 score: 6.5

Description: In libexpat before 2.7.4, the doContent function does not properly determine the buffer size bufSize because there is no integer overflow check for tag buffer reallocation.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libexpat1 > 0-0 (version in image is 2.7.1-160000.2.2).

CVE-2025-37916 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:pds_core: remove write-after-free of client_idA use-after-free error popped up in stress testing:[Mon Apr 21 21:21:33 2025] BUG: KFENCE: use-after-free write in pdsc_auxbus_dev_del+0xef/0x160 [pds_core][Mon Apr 21 21:21:33 2025] Use-after-free write at 0x000000007013ecd1 (in kfence-#47):[Mon Apr 21 21:21:33 2025] pdsc_auxbus_dev_del+0xef/0x160 [pds_core][Mon Apr 21 21:21:33 2025] pdsc_remove+0xc0/0x1b0 [pds_core][Mon Apr 21 21:21:33 2025] pci_device_remove+0x24/0x70[Mon Apr 21 21:21:33 2025] device_release_driver_internal+0x11f/0x180[Mon Apr 21 21:21:33 2025] driver_detach+0x45/0x80[Mon Apr 21 21:21:33 2025] bus_remove_driver+0x83/0xe0[Mon Apr 21 21:21:33 2025] pci_unregister_driver+0x1a/0x80The actual device uninit usually happens on a separate threadscheduled after this code runs, but there is no guarantee of orderof thread execution, so this could be a problem. There's noactual need to clear the client_id at this point, so simplyremove the offending code.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38662 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: mediatek: mt8365-dai-i2s: pass correct size to mt8365_dai_set_privGiven mt8365_dai_set_priv allocate priv_size space to copy priv_data whichmeans we should pass mt8365_i2s_priv[i] or "struct mtk_afe_i2s_priv"instead of afe_priv which has the size of "struct mt8365_afe_private".Otherwise the KASAN complains about.[ 59.389765] BUG: KASAN: global-out-of-bounds in mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm]...[ 59.394789] Call trace:[ 59.395167] dump_backtrace+0xa0/0x128[ 59.395733] show_stack+0x20/0x38[ 59.396238] dump_stack_lvl+0xe8/0x148[ 59.396806] print_report+0x37c/0x5e0[ 59.397358] kasan_report+0xac/0xf8[ 59.397885] kasan_check_range+0xe8/0x190[ 59.398485] asan_memcpy+0x3c/0x98[ 59.399022] mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm][ 59.399928] mt8365_dai_i2s_register+0x1e8/0x2b0 [snd_soc_mt8365_pcm][ 59.400893] mt8365_afe_pcm_dev_probe+0x4d0/0xdf0 [snd_soc_mt8365_pcm][ 59.401873] platform_probe+0xcc/0x228[ 59.402442] really_probe+0x340/0x9e8[ 59.402992] driver_probe_device+0x16c/0x3f8[ 59.403638] driver_probe_device+0x64/0x1d8[ 59.404256] driver_attach+0x1dc/0x4c8[ 59.404840] bus_for_each_dev+0x100/0x190[ 59.405442] driver_attach+0x44/0x68[ 59.405980] bus_add_driver+0x23c/0x500[ 59.406550] driver_register+0xf8/0x3d0[ 59.407122] platform_driver_register+0x68/0x98[ 59.407810] mt8365_afe_pcm_driver_init+0x2c/0xff8 [snd_soc_mt8365_pcm]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38709 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:loop: Avoid updating block size under exclusive ownerSyzbot came up with a reproducer where a loop device block size ischanged underneath a mounted filesystem. This causes a mismatch betweenthe block device block size and the block size stored in the superblockcausing confusion in various places such as fs/buffer.c. The particularissue triggered by syzbot was a warning in __getblk_slow() due torequested buffer size not matching block device block size.Fix the problem by getting exclusive hold of the loop device to changeits block size. This fails if somebody (such as filesystem) has alreadyan exclusive ownership of the block device and thus prevents modifyingthe loop device under some exclusive owner which doesn't expect it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39759 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix race between quota disable and quota rescan ioctlThere's a race between a task disabling quotas and another running therescan ioctl that can result in a use-after-free of qgroup records fromthe fs_info->qgroup_tree rbtree.This happens as follows:1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan();2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info->qgroup_rescan_running is false (it wasn't set yet by task A);3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock;4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free.Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config().Also at btrfs_qgroup_rescan() don't start the rescan worker if quotaswere already disabled.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39866 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:fs: writeback: fix use-after-free in __mark_inode_dirty()An use-after-free issue occurred when __mark_inode_dirty() get thebdi_writeback that was in the progress of switching.CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1......pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __mark_inode_dirty+0x124/0x418lr : __mark_inode_dirty+0x118/0x418sp : ffffffc08c9dbbc0........Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198Root cause is:systemd-random-seed kworker----------------------------------------------------------------------___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issueFix this race condition by holding inode spinlock untilwb_wakeup_delayed() finished.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39945 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:cnic: Fix use-after-free bugs in cnic_delete_taskThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),which does not guarantee that the delayed work item 'delete_task' hasfully completed if it was already running. Additionally, the delayed workitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() onlyblocks and waits for work items that were already queued to theworkqueue prior to its invocation. Any work items submitted afterflush_workqueue() is called are not included in the set of tasks that theflush operation awaits. This means that after the cyclic work items havefinished executing, a delayed work item may still exist in the workqueue.This leads to use-after-free scenarios where the cnic_dev is deallocatedby cnic_free_dev(), while delete_task remains active and attempt todereference cnic_dev in cnic_delete_task().A typical race condition is illustrated below:CPU 0 (cleanup) | CPU 1 (delayed work callback)cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //useReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the cyclic delayed work item is properly canceled and that anyongoing execution of the work item completes before the cnic_dev isdeallocated. Furthermore, since cancel_delayed_work_sync() uses__flush_work(work, true) to synchronously wait for any currentlyexecuting instance of the work item to finish, the flush_workqueue()becomes redundant and should be removed.This bug was identified through static analysis. To reproduce the issueand validate the fix, I simulated the cnic PCI device in QEMU andintroduced intentional delays - such as inserting calls to ssleep()within the cnic_delete_task() function - to increase the likelihoodof triggering the bug.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40121 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mappingWhen an invalid value is passed via quirk option, currentlybytcr_rt5640 driver just ignores and leaves as is, which may lead tounepxected results like OOB access.This patch adds the sanity check and corrects the input mapping to thecertain default value if an invalid value is passed.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40154 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mappingWhen an invalid value is passed via quirk option, currentlybytcr_rt5640 driver only shows an error message but leaves as is.This may lead to unepxected results like OOB access.This patch corrects the input mapping to the certain default value ifan invalid value is passed.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40323 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: Set fb_display[i]->mode to NULL when the mode is releasedRecently, we discovered the following issue through syzkaller:BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0Read of size 4 at addr ff11000001b3c69c by task syz.xxx...Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7eBased on experimentation and analysis, during framebuffer unregistration,only the memory of fb_info->modelist is freed, without setting thecorresponding fb_display[i]->mode to NULL for the freed modes. This leadsto UAF issues during subsequent accesses. Here's an example of reproductionsteps:1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1;2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP);3. Switch console from fb to VGA (to allow normal rmmod of the ko);4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[];5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0.Add a check in do_unregister_framebuffer(): if the mode to be freed existsin fb_display[], set the corresponding mode pointer to NULL.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40342 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-fc: use lock accessing port_state and rport statenvme_fc_unregister_remote removes the remote port on a lport object atany point in time when there is no active association. This races withwith the reconnect logic, because nvme_fc_create_association is nottaking a lock to check the port_state and atomically increase theactive count on the rport.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40343 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-fc: avoid scheduling association deletion twiceWhen forcefully shutting down a port via the configfs interface,nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() andthen nvmet_disable_port(). Both functions will eventually schedule allremaining associations for deletion.The current implementation checks whether an association is about to beremoved, but only after the work item has already been scheduled. As aresult, it is possible for the first scheduled work item to free allresources, and then for the same work item to be scheduled again fordeletion.Because the association list is an RCU list, it is not possible to takea lock and remove the list entry directly, so it cannot be looked upagain. Instead, a flag (terminating) must be used to determine whetherthe association is already in the process of being deleted.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68283 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace BUG_ON with bounds check for map->max_osdOSD indexes come from untrusted network packets. Boundary checks areadded to validate these against map->max_osd.[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68748 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Fix UAF race between device unplug and FW event processingThe function panthor_fw_unplug() will free the FW memory sections.The problem is that there could still be pending FW events which are yetnot handled at this point. process_fw_events_work() can in this case tryto access said freed memory.Simply call disable_work_sync() to both drain and prevent futureinvocation of process_fw_events_work().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68800 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_mr: Fix use-after-free when updating multicast route statsCited commit added a dedicated mutex (instead of RTNL) to protect themulticast route list, so that it will not change while the driverperiodically traverses it in order to update the kernel about multicastroute stats that were queried from the device.One instance of list entry deletion (during route replace) was missedand it can result in a use-after-free [1].Fix by acquiring the mutex before deleting the entry from the list andreleasing it afterwards.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full)Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum]Call Trace: dump_stack_lvl+0xba/0x110 print_report+0x174/0x4f5 kasan_report+0xdf/0x110 mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30 Allocated by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30Freed by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x43/0x70 kfree+0x14e/0x700 mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23074 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Enforce that teql can only be used as root qdiscDesign intent of teql is that it is only supposed to be used as root qdisc.We need to check for that constraint.Although not important, I will describe the scenario that unearthed thisissue for the curious.GangMin Kim managed to concot a scenario as follows:ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s ── class 1:2 (weight=1, lmax=1514) teqlGangMin sends a packet which is enqueued to 1:1 (netem).Any invocation of dequeue by QFQ from this class will not return a packetuntil after 6.4s. In the meantime, a second packet is sent and it lands on1:2. teql's enqueue will return success and this will activate class 1:2.Main issue is that teql only updates the parent visible qlen (sch->q.qlen)at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql'speek always returns NULL), dequeue will never be called and thus the qlenwill remain as 0. With that in mind, when GangMin updates 1:2's lmax value,the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc'sqlen was not incremented, qfq fails to deactivate the class, but stillfrees its pointers from the aggregate. So when the first packet isrescheduled after 6.4 seconds (netem's delay), a dangling pointer isaccessed causing GangMin's causing a UAF.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-50142 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: validate new SA's prefixlen using SA family when sel.family is unsetThis expands the validation introduced in commit 07bf7908950a ("xfrm:Validate address prefix lengths in the xfrm selector.")syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INETBecause of the AF_UNSPEC selector, verify_newsa_info doesn't putlimits on prefixlen_{s,d}. But then copy_from_user_state setsx->sel.family to usersa.family (AF_INET). Do the same conversion inverify_newsa_info before validating prefixlen_{s,d}, since that's howprefixlen is going to be used later on.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-14017 Severity: Moderate CVSS3 score: 6.3

Description: When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,changing TLS options in one thread would inadvertently change them globallyand therefore possibly also affect other concurrently setup transfers.Disabling certificate verification for a specific transfer couldunintentionally disable the feature for other threads as well.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
curl < 8.14.1-160000.4.1 (version in image is 8.14.1-160000.2.2).

CVE-2025-38008 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:mm/page_alloc: fix race condition in unaccepted memory handlingThe page allocator tracks the number of zones that have unaccepted memoryusing static_branch_enc/dec() and uses that static branch in hot paths todetermine if it needs to deal with unaccepted memory.Borislav and Thomas pointed out that the tracking is racy: operations onstatic_branch are not serialized against adding/removing unaccepted pagesto/from the zone.Sanity checks inside static_branch machinery detects it:WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0The comment around the WARN() explains the problem: /* * Warn about the '-1' case though; since that means a * decrement is concurrent with a first (0->1) increment. IOW * people are trying to disable something that wasn't yet fully * enabled. This suggests an ordering problem on the user side. */The effect of this static_branch optimization is only visible onmicrobenchmark.Instead of adding more complexity around it, remove it altogether.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38300 Severity: Moderate CVSS3 score: 6.3

Description: 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 callingdma_unmap_single() on the "theend_iv" path.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38365 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix a race between renames and directory loggingWe have a race between a rename and directory inode logging that if ithappens and we crash/power fail before the rename completes, the next timethe filesystem is mounted, the log replay code will end up deleting thefile that was being renamed.This is best explained following a step by step analysis of an interleavingof 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 weare 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 Acalled btrfs_log_new_name(), which would update the log with the new namefor inode Y ("A/bar").Fix this by pinning the log root during renames before removing the olddirectory entry, and unpinning af---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38564 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Handle buffer mapping fail correctly in perf_mmap()After successful allocation of a buffer or a successful attachment to anexisting buffer perf_mmap() tries to map the buffer read only into the pagetable. If that fails, the already set up page table entries are zapped, butthe other perf specific side effects of that failure are not handled. Thecalling code just cleans up the VMA and does not invoke perf_mmap_close().This leaks reference counts, corrupts user->vm accounting and also resultsin an unbalanced invocation of event::event_mapped().Cure this by moving the event::event_mapped() invocation before themap_range() call so that on map_range() failure perf_mmap_close() can beinvoked without causing an unbalanced event::event_unmapped() call.perf_mmap_close() undoes the reference counts and eventually frees buffers.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38713 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()The hfsplus_readdir() method is capable to crash by callinghfsplus_uni2asc():[ 667.121659][ T9805] ==================================================================[ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10[ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805[ 667.124578][ T9805][ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)[ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 667.124890][ T9805] Call Trace:[ 667.124893][ T9805] [ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0[ 667.124911][ T9805] print_report+0xd0/0x660[ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610[ 667.124928][ T9805] ? __phys_addr+0xe8/0x180[ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10[ 667.124942][ T9805] kasan_report+0xc6/0x100[ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10[ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10[ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360[ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0[ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10[ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0[ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20[ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0[ 667.125022][ T9805] ? lock_acquire+0x30/0x80[ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20[ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0[ 667.125044][ T9805] ? putname+0x154/0x1a0[ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10[ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0[ 667.125069][ T9805] iterate_dir+0x296/0xb20[ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0[ 667.125084][ T9805] ? __pfx___x64_sys_getdents64+0x10/0x10[ 667.125091][ T9805] ? __x64_sys_openat+0x141/0x200[ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10[ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0[ 667.125143][ T9805] do_syscall_64+0xc9/0x480[ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9[ 667.125164][ T9805] Code: 00 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 48[ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9[ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9[ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004[ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110[ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260[ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[ 667.125207][ T9805] [ 667.125210][ T9805][ 667.145632][ T9805] Allocated by task 9805:[ 667.145991][ T9805] kasan_save_stack+0x20/0x40[ 667.146352][ T9805] kasan_save_track+0x14/0x30[ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0[ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550[ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0[ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0[ 667.148174][ T9805] iterate_dir+0x296/0xb20[ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0[ 667.148937][ T9805] do_syscall_64+0xc9/0x480[ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 667.149809][ T9805][ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000[ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048[ 667.151282][ T9805] The buggy address is located 0 bytes to the right of[ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)[ 667.1---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38714 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()The hfsplus_bnode_read() method can trigger the issue:[ 174.852007][ T9784] ==================================================================[ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360[ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784[ 174.854059][ T9784][ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)[ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 174.854286][ T9784] Call Trace:[ 174.854289][ T9784] [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0[ 174.854305][ T9784] print_report+0xd0/0x660[ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610[ 174.854323][ T9784] ? __phys_addr+0xe8/0x180[ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360[ 174.854337][ T9784] kasan_report+0xc6/0x100[ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360[ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360[ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380[ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10[ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0[ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310[ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40[ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0[ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0[ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10[ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10[ 174.854436][ T9784] ? __asan_memset+0x23/0x50[ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320[ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10[ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0[ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40[ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0[ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10[ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0[ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10[ 174.854525][ T9784] ? down_write+0x148/0x200[ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10[ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0[ 174.854549][ T9784] do_unlinkat+0x490/0x670[ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10[ 174.854565][ T9784] ? __might_fault+0xbc/0x130[ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550[ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110[ 174.854592][ T9784] do_syscall_64+0xc9/0x480[ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167[ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08[ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057[ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167[ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50[ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40[ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0[ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[ 174.854658][ T9784] [ 174.854661][ T9784][ 174.879281][ T9784] Allocated by task 9784:[ 174.879664][ T9784] kasan_save_stack+0x20/0x40[ 174.880082][ T9784] kasan_save_track+0x14/0x30[ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0[ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550[ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890[ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10[ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520[ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39926 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:genetlink: fix genl_bind() invoking bind() after -EPERMPer family bind/unbind callbacks were introduced to allow familiesto track multicast group consumer presence, e.g. to start or stopproducing events depending on listeners.However, in genl_bind() the bind() callback was invoked even ifcapability checks failed and ret was set to -EPERM. This means thatcallbacks could run on behalf of unauthorized callers while thesyscall still returned failure to user space.Fix this by only invoking bind() after "if (ret) break;" checki.e. after permission checks have succeeded.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40043 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: nfc: nci: Add parameter validation for packet dataSyzbot reported an uninitialized value bug in nci_init_req, which wasintroduced by commit 5aca7966d2a7 ("Merge tag'perf-tools-fixes-for-v6.17-2025-09-16' ofgit://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").This bug arises due to very limited and poor input validationthat was done at nic_valid_size(). This validation onlyvalidates the skb->len (directly reflects size provided at theuserspace interface) with the length provided in the bufferitself (interpreted as NCI_HEADER). This leads to the processingof memory content at the address assuming the correct layoutper what opcode requires there. This leads to the accesses tobuffer of `skb_buff->data` which is not assigned anything yet.Following the same silent drop of packets of invalid sizes at`nic_valid_size()`, add validation of the data in the respectivehandlers and return error values in case of failure. Releasethe skb if error values are returned from handlers in`nci_nft_packet` and effectively do a silent dropPossible TODO: because we silently drop the packets, thecall to `nci_request` will be waiting for completion of requestand will face timeouts. These timeouts can get excessively loggedin the dmesg. A proper handling of them may require to export`nci_request_cancel` (or propagate error handling from thenft packets handlers).

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40044 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:fs: udf: fix OOB read in lengthAllocDescs handlingWhen parsing Allocation Extent Descriptor, lengthAllocDescs comes fromon-disk data and must be validated against the block size. Crafted orcorrupted images may set lengthAllocDescs so that the total descriptorlength (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory andtrigger a KASAN use-after-free read.BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Call Trace: __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:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261 udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179 extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46 udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106 udf_release_file+0xc1/0x120 fs/udf/file.c:185 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Validate the computed total length against epos->bh->b_size.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40091 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ixgbe: fix too early devlink_free() in ixgbe_remove()Since ixgbe_adapter is embedded in devlink, calling devlink_free()prematurely in the ixgbe_remove() path can lead to UAF. Move devlink_free()to the end.KASAN report: BUG: KASAN: use-after-free in ixgbe_reset_interrupt_capability+0x140/0x180 [ixgbe] Read of size 8 at addr ffff0000adf813e0 by task bash/2095 CPU: 1 UID: 0 PID: 2095 Comm: bash Tainted: G S 6.17.0-rc2-tnguy.net-queue+ #1 PREEMPT(full) [...] Call trace: show_stack+0x30/0x90 (C) dump_stack_lvl+0x9c/0xd0 print_address_description.constprop.0+0x90/0x310 print_report+0x104/0x1f0 kasan_report+0x88/0x180 __asan_report_load8_noabort+0x20/0x30 ixgbe_reset_interrupt_capability+0x140/0x180 [ixgbe] ixgbe_clear_interrupt_scheme+0xf8/0x130 [ixgbe] ixgbe_remove+0x2d0/0x8c0 [ixgbe] pci_device_remove+0xa0/0x220 device_remove+0xb8/0x170 device_release_driver_internal+0x318/0x490 device_driver_detach+0x40/0x68 unbind_store+0xec/0x118 drv_attr_store+0x64/0xb8 sysfs_kf_write+0xcc/0x138 kernfs_fop_write_iter+0x294/0x440 new_sync_write+0x1fc/0x588 vfs_write+0x480/0x6a0 ksys_write+0xf0/0x1e0 __arm64_sys_write+0x70/0xc0 invoke_syscall.constprop.0+0xcc/0x280 el0_svc_common.constprop.0+0xa8/0x248 do_el0_svc+0x44/0x68 el0_svc+0x54/0x160 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40141 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: ISO: Fix possible UAF on iso_conn_freeThis attempt to fix similar issue to sco_conn_free where if theconn->sk is not set to NULL may lead to UAF on iso_conn_free.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40149 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().get_netdev_for_sock() is called during setsockopt(),so not under RCU.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().Note that the only ->ndo_sk_get_lower_dev() user isbond_sk_get_lower_dev(), which uses RCU.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40158 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_output()Use RCU in ip6_output() in order to use dst_dev_rcu() to preventpossible UAF.We can remove rcu_read_lock()/rcu_read_unlock() pairsfrom ip6_finish_output2().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40168 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().smc_clc_prfx_match() is called from smc_listen_work() andnot under RCU nor RTNL.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().Note that the returned value of smc_clc_prfx_match() is notused in the caller.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40170 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: use dst_dev_rcu() in sk_setup_caps()Use RCU to protect accesses to dst->dev from sk_setup_caps()and sk_dst_gso_max_size().Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),and ip_dst_mtu_maybe_forward().ip4_dst_hoplimit() can use dst_dev_net_rcu().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40177 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:accel/qaic: Fix bootlog initialization orderingAs soon as we queue MHI buffers to receive the bootlog from the device,we could be receiving data. Therefore all the resources needed toprocess that data need to be setup prior to queuing the buffers.We currently initialize some of the resources after queuing the bufferswhich creates a race between the probe() and any data that comes backfrom the device. If the uninitialized resources are accessed, we couldsee page faults.Fix the init ordering to close the race.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40180 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loopThe cleanup loop was starting at the wrong array index, causingout-of-bounds access.Start the loop at the correct index for zero-indexed arrays to preventaccessing memory beyond the allocated array bounds.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40211 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: video: Fix use-after-free in acpi_video_switch_brightness()The switch_brightness_work delayed work accesses device->brightnessand device->backlight, freed by acpi_video_dev_unregister_backlight()during device removal.If the work executes after acpi_video_bus_unregister_backlight()frees these resources, it causes a use-after-free whenacpi_video_switch_brightness() dereferences device->brightness ordevice->backlight.Fix this by calling cancel_delayed_work_sync() for each device'sswitch_brightness_work in acpi_video_bus_remove_notify_handler()after removing the notify handler that queues the work. This ensuresthe work completes before the memory is freed.[ rjw: Changelog edit ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40221 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:media: pci: mg4b: fix uninitialized iio scan dataFix potential leak of uninitialized stack data to userspace by ensuringthat the `scan` structure is zeroed before use.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40302 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:media: videobuf2: forbid remove_bufs when legacy fileio is activevb2_ioctl_remove_bufs() call manipulates queue internal buffer list,potentially overwriting some pointers used by the legacy fileio accessmode. Forbid that ioctl when fileio is active to protect internal queuestate between subsequent read/write calls.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68188 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()Use RCU to avoid a pair of atomic operations and a potentialUAF on dst_dev()->flags.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68255 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsingThe Supported Rates IE length from an incoming Association Request framewas used directly as the memcpy() length when copying into a fixed-size16-byte stack buffer (supportRate). A malicious station can advertise anIE length larger than 16 bytes, causing a stack buffer overflow.Clamp ie_len to the buffer size before copying the Supported Rates IE,and correct the bounds check when merging Extended Supported Rates toprevent a second potential overflow.This prevents kernel stack corruption triggered by malformed associationrequests.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68264 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: refresh inline data size before write operationsThe cached ei->i_inline_size can become stale between the initial sizecheck and when ext4_update_inline_data()/ext4_create_inline_data() useit. Although ext4_get_max_inline_size() reads the correct value at thetime of the check, concurrent xattr operations can modify i_inline_sizebefore ext4_write_lock_xattr() is acquired.This causes ext4_update_inline_data() and ext4_create_inline_data() towork with stale capacity values, leading to a BUG_ON() crash inext4_write_inline_data(): kernel BUG at fs/ext4/inline.c:1331! BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);The race window:1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)2. Size check passes for 50-byte write3. [Another thread adds xattr, i_inline_size changes to 40]4. ext4_write_lock_xattr() acquires lock5. ext4_update_inline_data() uses stale i_inline_size = 606. Attempts to write 50 bytes but only 40 bytes actually available7. BUG_ON() triggersFix this by recalculating i_inline_size via ext4_find_inline_data_nolock()immediately after acquiring xattr_sem. This ensures ext4_update_inline_data()and ext4_create_inline_data() work with current values that are protectedfrom concurrent modifications.This is similar to commit a54c4613dac1 ("ext4: fix race writing to aninline_data file while its xattrs are changing") which fixed i_inline_offstaleness. This patch addresses the related i_inline_size staleness issue.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68331 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transferWhen a UAS device is unplugged during data transfer, there isa probability of a system panic occurring. The root cause isan access to an invalid memory address during URB callback handling.Specifically, this happens when the dma_direct_unmap_sg() functionis called within the usb_hcd_unmap_urb_for_dma() interface, but thesg->dma_address field is 0 and the sg data structure has already beenfreed.The SCSI driver sends transfer commands by invoking uas_queuecommand_lck()in uas.c, using the uas_submit_urbs() function to submit requests to USB.Within the uas_submit_urbs() implementation, three URBs (sense_urb,data_urb, and cmd_urb) are sequentially submitted. Device removal mayoccur at any point during uas_submit_urbs execution, which may resultin URB submission failure. However, some URBs might have been successfullysubmitted before the failure, and uas_submit_urbs will return the -ENODEVerror code in this case. The current error handling directly callsscsi_done(). In the SCSI driver, this eventually triggers scsi_complete()to invoke scsi_end_request() for releasing the sgtable. The successfullysubmitted URBs, when being unlinked to giveback, callusb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sgunmapping operations since the sg data structure has already been freed.This patch modifies the error condition check in the uas_submit_urbs()function. When a UAS device is removed but one or more URBs have alreadybeen successfully submitted to USB, it avoids immediately invokingscsi_done() and save the cmnd to devinfo->cmnd array. If the successfullysubmitted URBs is completed before devinfo->resetting being set, thenthe scsi_done() function will be called within uas_try_complete() afterall pending URB operations are finalized. Otherwise, the scsi_done()function will be called within uas_zap_pending(), which is executed afterusb_kill_anchored_urbs().The error handling only takes effect when uas_queuecommand_lck() callsuas_submit_urbs() and returns the error value -ENODEV . In this case,the device is disconnected, and the flow proceeds to uas_disconnect(),where uas_zap_pending() is invoked to call uas_try_complete().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68339 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:atm/fore200e: Fix possible data race in fore200e_open()Protect access to fore200e->available_cell_rate with rate_mtx lock in theerror handling path of fore200e_open() to prevent a data race.The field fore200e->available_cell_rate is a shared resource used to trackavailable bandwidth. It is concurrently accessed by fore200e_open(),fore200e_close(), and fore200e_change_qos().In fore200e_open(), the lock rate_mtx is correctly held when subtractingvcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth.However, if the subsequent call to fore200e_activate_vcin() fails, thefunction restores the reserved bandwidth by adding back toavailable_cell_rate without holding the lock.This introduces a race condition because available_cell_rate is a globaldevice resource shared across all VCCs. If the error path infore200e_open() executes concurrently with operations likefore200e_close() or fore200e_change_qos() on other VCCs, aread-modify-write race occurs.Specifically, the error path reads the rate without the lock. If anotherCPU acquires the lock and modifies the rate (e.g., releasing bandwidth infore200e_close()) between this read and the subsequent write, the errorpath will overwrite the concurrent update with a stale value. This resultsin incorrect bandwidth accounting.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68785 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix middle attribute validation in push_nsh() actionThe push_nsh() action structure looks like this: OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))The outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK'ed by thenla_for_each_nested() inside __ovs_nla_copy_actions(). The innermostOVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK'ed by the nla_for_each_nested()inside nsh_key_put_from_nlattr(). But nothing checks if the attributein the middle is OK. We don't even check that this attribute is theOVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data()calls - first time directly while calling validate_push_nsh() and thesecond time as part of the nla_for_each_nested() macro, which isn'tsafe, potentially causing invalid memory access if the size of thisattribute is incorrect. The failure may not be noticed duringvalidation due to larger netlink buffer, but cause trouble later duringaction execution where the buffer is allocated exactly to the size: BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] Read of size 184 at addr ffff88816459a634 by task a.out/22624 CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary) Call Trace: dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x2c/0x390 kasan_report+0xdd/0x110 kasan_check_range+0x35/0x1b0 __asan_memcpy+0x20/0x60 nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] push_nsh+0x82/0x120 [openvswitch] do_execute_actions+0x1405/0x2840 [openvswitch] ovs_execute_actions+0xd5/0x3b0 [openvswitch] ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch] genl_family_rcv_msg_doit+0x1d6/0x2b0 genl_family_rcv_msg+0x336/0x580 genl_rcv_msg+0x9f/0x130 netlink_rcv_skb+0x11f/0x370 genl_rcv+0x24/0x40 netlink_unicast+0x73e/0xaa0 netlink_sendmsg+0x744/0xbf0 __sys_sendto+0x3d6/0x450 do_syscall_64+0x79/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Let's add some checks that the attribute is properly sized and it'sthe only one attribute inside the action. Technically, there is noreal reason for OVS_KEY_ATTR_NSH to be there, as we know that we'repushing an NSH header already, it just creates extra nesting, butthat's how uAPI works today. So, keeping as it is.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68792 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:tpm2-sessions: Fix out of range indexing in name_size'name_size' does not have any range checks, and it just directly indexeswith TPM_ALG_ID, which could lead into memory corruption at worst.Address the issue by only processing known values and returning -EINVAL forunrecognized values.Make also 'tpm_buf_append_name' and 'tpm_buf_fill_hmac_session' fallible sothat errors are detected before causing any spurious TPM traffic.End also the authorization session on failure in both of the functions, asthe session state would be then by definition corrupted.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68794 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:iomap: adjust read range correctly for non-block-aligned positionsiomap_adjust_read_range() assumes that the position and length passed inare block-aligned. This is not always the case however, as shown in thesyzbot generated case for erofs. This causes too many bytes to beskipped for uptodate blocks, which results in returning the incorrectposition and length to read in. If all the blocks are uptodate, thisunderflows length and returns a position beyond the folio.Fix the calculation to also take into account the block offset whencalculating how many bytes can be skipped for uptodate blocks.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71116 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make decode_pool() more resilient against corrupted osdmapsIf the osdmap is (maliciously) corrupted such that the encoded lengthof ceph_pg_pool envelope is less than what is expected for a particularencoding version, out-of-bounds reads may ensue because the only boundscheck that is there is based on that length value.This patch adds explicit bounds checks for each field that is decodedor skipped.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71149 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/poll: correctly handle io_poll_add() return value on updateWhen the core of io_uring was updated to handle completionsconsistently and with fixed return codes, the POLL_REMOVE opcodewith updates got slightly broken. If a POLL_ADD is pending andthen POLL_REMOVE is used to update the events of that request, if thatupdate causes the POLL_ADD to now trigger, then that completion is lostand a CQE is never posted.Additionally, ensure that if an update does cause an existing POLL_ADDto complete, that the completion value isn't always overwritten with-ECANCELED. For that case, whatever io_poll_add() set the value toshould just be retained.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71152 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: properly keep track of conduit referenceProblem description-------------------DSA has a mumbo-jumbo of reference handling of the conduit net deviceand its kobject which, sadly, is just wrong and doesn't make sense.There are two distinct problems.1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch:(unbind the conduit driver for net device eno2)echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbindwe see these lines in the output diff which appear only with the patchapplied:kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()).Actually we actually use that netdev tracker mechanism implicitly onuser ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces withthe DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link().But time still passes at DSA switch probe time between the initialof_find_net_device_by_node() code and the user port creation time, timeduring which the conduit could unregister itself and DSA wouldn't knowabout it.So we have to run of_find_net_device_by_node() under rtnl_lock() toprevent that from happening, and release the lock only with the netdevtracker having acquired the reference.Do we need to keep the reference until dsa_unregister_switch() /dsa_switch_shutdown()?1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference.2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.As for the conduit's kobject for the /sys/class/net/ entry, we don'tcare about it, we can release it as soon as we hold the net deviceobject itself.History and blame attribution-----------------------------The code has been refactored so many times, it is very difficult tofollow and properly attribute a blame, but I'll try to make a shorthistory which I hope to be correct.We have two distinct probing paths:- one for OF, introduced in 2016 i---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-15469 Severity: Moderate CVSS3 score: 6.2

Description: Issue summary: The 'openssl dgst' command-line tool silently truncates inputdata to 16MB when using one-shot signing algorithms and reports success insteadof an error.Impact summary: A user signing or verifying files larger than 16MB withone-shot algorithms (such as Ed25519, Ed448, or ML-DSA) may believe the entirefile is authenticated while trailing data beyond 16MB remains unauthenticated.When the 'openssl dgst' command is used with algorithms that only supportone-shot signing (Ed25519, Ed448, ML-DSA-44, ML-DSA-65, ML-DSA-87), the inputis buffered with a 16MB limit. If the input exceeds this limit, the toolsilently truncates to the first 16MB and continues without signaling an error,contrary to what the documentation states. This creates an integrity gap wheretrailing bytes can be modified without detection if both signing andverification are performed using the same affected codepath.The issue affects only the command-line tool behavior. Verifiers that processthe full message using library APIs will reject the signature, so the riskprimarily affects workflows that both sign and verify with the affected'openssl dgst' command. Streaming digest algorithms for 'openssl dgst' andlibrary users are unaffected.The FIPS modules in 3.5 and 3.6 are not affected by this issue, as thecommand-line tools are outside the OpenSSL FIPS module boundary.OpenSSL 3.5 and 3.6 are vulnerable to this issue.OpenSSL 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.5.1 (version in image is 3.5.0-160000.3.2).

CVE-2025-37849 Severity: Moderate CVSS3 score: 6.2

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Tear down vGIC on failed vCPU creationIf kvm_arch_vcpu_create() fails to share the vCPU page with thehypervisor, we propagate the error back to the ioctl but leave thevGIC vCPU data initialised. Note only does this leak the correspondingmemory when the vCPU is destroyed but it can also lead to use-after-freeif the redistributor device handling tries to walk into the vCPU.Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that thevGIC vCPU structures are destroyed on error.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-54389 Severity: Moderate CVSS3 score: 6.2

Description: AIDE is an advanced intrusion detection environment. Prior to version 0.19.2, there is an improper output neutralization vulnerability in AIDE. An attacker can craft a malicious filename by including terminal escape sequences to hide the addition or removal of the file from the report and/or tamper with the log output. A local user might exploit this to bypass the AIDE detection of malicious files. Additionally the output of extended attribute key names and symbolic links targets are also not properly neutralized. This issue has been patched in version 0.19.2. A workaround involves configuring AIDE to write the report output to a regular file, redirecting stdout to a regular file, or redirecting the log output written to stderr to a regular file.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
aide > 0-0 (version in image is 0.18.8-160000.2.2).

CVE-2025-68160 Severity: Moderate CVSS3 score: 6.2

Description: Issue summary: Writing large, newline-free data into a BIO chain using theline-buffering filter where the next BIO performs short writes can triggera heap-based out-of-bounds write.Impact summary: This out-of-bounds write can cause memory corruption whichtypically results in a crash, leading to Denial of Service for an application.The line-buffering BIO filter (BIO_f_linebuffer) is not used by default inTLS/SSL data paths. In OpenSSL command-line applications, it is typicallyonly pushed onto stdout/stderr on VMS systems. Third-party applications thatexplicitly use this filter with a BIO chain that can short-write and thatwrite large, newline-free data influenced by an attacker would be affected.However, the circumstances where this could happen are unlikely to be underattacker control, and BIO_f_linebuffer is unlikely to be handling non-curateddata controlled by an attacker. For that reason the issue was assessed asLow severity.The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the BIO implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.5.1 (version in image is 3.5.0-160000.3.2).

CVE-2025-69419 Severity: Moderate CVSS3 score: 6.2

Description: Issue summary: Calling PKCS12_get_friendlyname() function on a maliciouslycrafted PKCS#12 file with a BMPString (UTF-16BE) friendly name containingnon-ASCII BMP code point can trigger a one byte write before the allocatedbuffer.Impact summary: The out-of-bounds write can cause a memory corruptionwhich can have various consequences including a Denial of Service.The OPENSSL_uni2utf8() function performs a two-pass conversion of a PKCS#12BMPString (UTF-16BE) to UTF-8. In the second pass, when emitting UTF-8 bytes,the helper function bmp_to_utf8() incorrectly forwards the remaining UTF-16source byte count as the destination buffer capacity to UTF8_putc(). For BMPcode points above U+07FF, UTF-8 requires three bytes, but the forwardedcapacity can be just two bytes. UTF8_putc() then returns -1, and this negativevalue is added to the output length without validation, causing thelength to become negative. The subsequent trailing NUL byte is then writtenat a negative offset, causing write outside of heap allocated buffer.The vulnerability is reachable via the public PKCS12_get_friendlyname() APIwhen parsing attacker-controlled PKCS#12 files. While PKCS12_parse() uses adifferent code path that avoids this issue, PKCS12_get_friendlyname() directlyinvokes the vulnerable function. Exploitation requires an attacker to providea malicious PKCS#12 file to be parsed by the application and the attackercan just trigger a one zero byte write before the allocated buffer.For that reason the issue was assessed as Low severity according to ourSecurity Policy.The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.OpenSSL 1.0.2 is not affected by this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.5.1 (version in image is 3.5.0-160000.3.2).

CVE-2025-69421 Severity: Moderate CVSS3 score: 6.2

Description: Issue summary: Processing a malformed PKCS#12 file can trigger a NULL pointerdereference in the PKCS12_item_decrypt_d2i_ex() function.Impact summary: A NULL pointer dereference can trigger a crash which leads toDenial of Service for an application processing PKCS#12 files.The PKCS12_item_decrypt_d2i_ex() function does not check whether the octparameter is NULL before dereferencing it. When called fromPKCS12_unpack_p7encdata() with a malformed PKCS#12 file, this parameter canbe NULL, causing a crash. The vulnerability is limited to Denial of Serviceand cannot be escalated to achieve code execution or memory disclosure.Exploiting this issue requires an attacker to provide a malformed PKCS#12 fileto an application that processes it. For that reason the issue was assessed asLow severity according to our Security Policy.The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.5.1 (version in image is 3.5.0-160000.3.2).

CVE-2026-22795 Severity: Moderate CVSS3 score: 6.2

Description: Issue summary: An invalid or NULL pointer dereference can happen inan application processing a malformed PKCS#12 file.Impact summary: An application processing a malformed PKCS#12 file can becaused to dereference an invalid or NULL pointer on memory read, resultingin a Denial of Service.A type confusion vulnerability exists in PKCS#12 parsing code wherean ASN1_TYPE union member is accessed without first validating the type,causing an invalid pointer read.The location is constrained to a 1-byte address space, meaning anyattempted pointer manipulation can only target addresses between 0x00 and 0xFF.This range corresponds to the zero page, which is unmapped on most modernoperating systems and will reliably result in a crash, leading only to aDenial of Service. Exploiting this issue also requires a user or applicationto process a maliciously crafted PKCS#12 file. It is uncommon to acceptuntrusted PKCS#12 files in applications as they are usually used to storeprivate keys which are trusted by definition. For these reasons, the issuewas assessed as Low severity.The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the PKCS12 implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.OpenSSL 1.0.2 is not affected by this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.5.1 (version in image is 3.5.0-160000.3.2).

CVE-2024-53138 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: kTLS, Fix incorrect page refcountingThe kTLS tx handling code is using a mix of get_page() andpage_ref_inc() APIs to increment the page reference. But on the releasepath (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.This is an issue when using pages from large folios: the get_page()references are stored on the folio page while the page_ref_inc()references are stored directly in the given page. On release the foliopage will be dereferenced too many times.This was found while doing kTLS testing with sendfile() + ZC when theserved file was read from NFS on a kernel with NFS large folios support(commit 49b29a573da8 ("nfs: add support for large folios")).

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-11412 Severity: Moderate CVSS3 score: 6.1

Description: A vulnerability has been found in GNU Binutils 2.45. This impacts the function bfd_elf_gc_record_vtentry of the file bfd/elflink.c of the component Linker. The manipulation leads to out-of-bounds read. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The identifier of the patch is 047435dd988a3975d40c6626a8f739a0b2e154bc. To fix this issue, it is recommended to deploy a patch.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-11413 Severity: Moderate CVSS3 score: 6.1

Description: A vulnerability was found in GNU Binutils 2.45. Affected is the function elf_link_add_object_symbols of the file bfd/elflink.c of the component Linker. The manipulation results in out-of-bounds read. The attack needs to be approached locally. The exploit has been made public and could be used. Upgrading to version 2.46 is able to address this issue. The patch is identified as 72efdf166aa0ed72ecc69fc2349af6591a7a19c0. Upgrading the affected component is advised.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-11414 Severity: Moderate CVSS3 score: 6.1

Description: A vulnerability was determined in GNU Binutils 2.45. Affected by this vulnerability is the function get_link_hash_entry of the file bfd/elflink.c of the component Linker. This manipulation causes out-of-bounds read. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. Upgrading to version 2.46 addresses this issue. Patch name: aeaaa9af6359c8e394ce9cf24911fec4f4d23703. It is advisable to upgrade the affected component.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-38006 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: mctp: Don't access ifa_index when missingIn mctp_dump_addrinfo, ifa_index can be used to filter interfaces, butonly when the struct ifaddrmsg is provided. Otherwise it will becomparing to uninitialised memory - reproducible in the syzkaller case fromdhcpd, or busybox "ip addr show".The kernel MCTP implementation has always filtered by ifa_index, soexisting userspace programs expecting to dump MCTP addresses mustalready be passing a valid ifa_index value (either 0 or a real index).BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38149 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: clear phydev->devlink when the link is deletedThere is a potential crash issue when disabling and re-enabling thenetwork port. When disabling the network port, phy_detach() callsdevice_link_del() to remove the device link, but it does not clearphydev->devlink, so phydev->devlink is not a NULL pointer. Then thenetwork port is re-enabled, but if phy_attach_direct() fails beforecalling device_link_add(), the code jumps to the "error" label andcalls phy_detach(). Since phydev->devlink retains the old value fromthe previous attach/detach cycle, device_link_del() uses the old value,which accesses a NULL pointer and causes a crash. The simplified crashlog 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/0x34Therefore, phydev->devlink needs to be cleared when the device link isdeleted.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38151 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cma: Fix hang when cma_netevent_callback fails to queue_workThe cited commit fixed a crash when cma_netevent_callback was called fora 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 thework item currently in the work queue.However, it left a problem when queue_work fails (because the item isstill pending in the work queue from a previous call). In this case,cma_id_put (which is called in the work handler) is therefore notcalled. This results in a userspace process hang (zombie process).Fix this by calling cma_id_put() if queue_work fails.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38168 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:perf: arm-ni: Unregister PMUs on probe failureWhen a resource allocation fails in one clock domain of an NI device,we need to properly roll back all previously registered perf PMUs inother clock domains of the same device.Otherwise, it can lead to kernel panics.Calling arm_ni_init+0x0/0xff8 [arm_ni] @ 2374arm-ni ARMHCB70:00: Failed to request PMU region 0x1f3c13000arm-ni ARMHCB70:00: probe with driver arm-ni failed with error -16list_add corruption: next->prev should be prev (fffffd01e9698a18),but was 0000000000000000. (next=ffff10001a0decc8).pstate: 6340009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)pc : list_add_valid_or_report+0x7c/0xb8lr : list_add_valid_or_report+0x7c/0xb8Call trace: __list_add_valid_or_report+0x7c/0xb8 perf_pmu_register+0x22c/0x3a0 arm_ni_probe+0x554/0x70c [arm_ni] platform_probe+0x70/0xe8 really_probe+0xc6/0x4d8 driver_probe_device+0x48/0x170 __driver_attach+0x8e/0x1c0 bus_for_each_dev+0x64/0xf0 driver_add+0x138/0x260 bus_add_driver+0x68/0x138 __platform_driver_register+0x2c/0x40 arm_ni_init+0x14/0x2a [arm_ni] do_init_module+0x36/0x298---[ end trace 0000000000000000 ]---Kernel panic - not syncing: Oops - BUG: Fatal exceptionSMP: stopping secondary CPUs

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38193 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: reject invalid perturb periodGerrard 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 overflowand is positive.tc qd add dev lo root sfq perturb -10 # negative value : errorError: sch_sfq: invalid perturb period.tc qd add dev lo root sfq perturb 1000000000 # too big : errorError: sch_sfq: invalid perturb period.tc qd add dev lo root sfq perturb 2000000 # acceptable valuetc -s -d qd sh dev loqdisc 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38197 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell_rbu: Fix list usagePass the correct list head to list_for_each_entry*() when looping throughthe packet list.Without this patch, reading the packet data via sysfs will show the dataincorrectly (because it starts at the wrong packet), and clearing thepacket list will result in a NULL pointer dereference.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38211 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix use-after-free of work objects after cm_id destructionThe commit 59c68ac31e15 ("iw_cm: free cm_id resources on the lastderef") simplified cm_id resource management by freeing cm_id once allreferences to the cm_id were removed. The references are removed eitherupon completion of iw_cm event handlers or when the application destroysthe cm_id. This commit introduced the use-after-free condition wherecm_id_private object could still be in use by event handler works duringthe destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix ause-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 happenswith the work objects allocated for each cm_id_priv withinalloc_work_entries() during cm_id creation, and subsequently freed indealloc_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: 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 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/0x30This BUG is reproducible by repeating the blktests test case nvme/061for the rdma transport and the siw driver.To avoid the use-after-free of cm_id_private work objects, ensure thatthe last reference to the cm_id is decremented not in the event handlerworks, but in the cm_id destruction context. For that purpose, mo---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38222 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: inline: fix len overflow in ext4_prepare_inline_dataWhen running the following code on an ext4 filesystem with inline_datafeature 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 whenext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + lenwill be truncated, leading to ext4_prepare_inline_data parameter to be 6instead 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 inext4_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] [ 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---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38249 Severity: Moderate CVSS3 score: 6.1

Description: 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 fromsnd_usb_ctl_msg() is used directly for memory allocation withoutvalidation. This length is controlled by the USB device.The allocated buffer is cast to a uac3_cluster_header_descriptorand its fields are accessed without verifying that the bufferis large enough. If the device returns a smaller than expectedlength, this leads to an out-of-bounds read.Add a length check to ensure the buffer is large enough foruac3_cluster_header_descriptor.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38292 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: fix invalid access to memoryIn ath12k_dp_rx_msdu_coalesce(), rxcb is fetched from skb and booleanis_continuation is part of rxcb.Currently, after freeing the skb, the rxcb->is_continuation accessedagain 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.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38303 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: eir: Fix possible crashes on eir_create_adv_dataeir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWERwithout checking if that would fit.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38401 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:mtk-sd: Prevent memory corruption from DMA map failureIf msdc_prepare_data() fails to map the DMA region, the request isnot prepared for data receiving, but msdc_start_data() proceedsthe DMA with previous setting.Since this will lead a memory corruption, we have to stop therequest operation soon after the msdc_prepare_data() fails toprepare it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38403 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:vsock/vmci: Clear the vmci transport packet properly when initializing itIn vmci_transport_packet_init memset the vmci_transport_packet beforepopulating the fields to avoid any uninitialised data being left in thestructure.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38413 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:virtio-net: xsk: rx: fix the frame's length checkWhen calling buf_to_xdp, the len argument is the frame data's lengthwithout virtio header's length (vi->hdr_len). We check that len with xsk_pool_get_rx_frame_size() + vi->hdr_lento ensure the provided len does not larger than the allocated chunksize. The additional vi->hdr_len is because in virtnet_add_recvbuf_xsk,we use part of XDP_PACKET_HEADROOM for virtio header and ask the vhostto start placing data from hard_start + XDP_PACKET_HEADROOM - vi->hdr_lennot hard_start + XDP_PACKET_HEADROOMBut the first buffer has virtio_header, so the maximum frame's length inthe first buffer can only be xsk_pool_get_rx_frame_size()not xsk_pool_get_rx_frame_size() + vi->hdr_lenlike in the current check.This commit adds an additional argument to buf_to_xdp differentiatebetween the first buffer and other ones to correctly calculate the maximumframe's length.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38425 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: tegra: check msg length in SMBUS block readFor SMBUS block read, do not continue to read if the message lengthpassed from the device is '0' or greater than the maximum allowed bytes.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38441 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: account for Ethernet header in nf_flow_pppoe_proto()syzbot found a potential access to uninit-value in nf_flow_pppoe_proto()Blamed commit forgot the Ethernet header.BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xe1/0x3d0 net/netfilter/core.c:623 nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline] nf_ingress net/core/dev.c:5742 [inline] __netif_receive_skb_core+0x4aff/0x70c0 net/core/dev.c:5837 __netif_receive_skb_one_core net/core/dev.c:5975 [inline] __netif_receive_skb+0xcc/0xac0 net/core/dev.c:6090 netif_receive_skb_internal net/core/dev.c:6176 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6235 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x4ee0/0x6b40 drivers/net/tun.c:1938 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1984 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xb4b/0x1580 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38443 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:nbd: fix uaf in nbd_genl_connect() error pathThere 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:1022Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67CPU: 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/2014Workqueue: nbd6-recv recv_workCall Trace: __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 nbd_genl_connect() does not properly stop the device on certainerror paths after nbd_start_device() has been called. This causesthe error path to put nbd->config while recv_work continue to usethe config after putting it, leading to use-after-free in recv_work.This patch moves nbd_start_device() after the backend file creation.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38456 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ipmi:msghandler: Fix potential memory corruption in ipmi_create_user()The "intf" list iterator is an invalid pointer if the correct"intf->intf_num" is not found. Calling atomic_dec(&intf->nr_users) onand invalid pointer will lead to memory corruption.We don't really need to call atomic_dec() if we haven't calledatomic_add_return() so update the if (intf->in_shutdown) path as well.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38463 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Correct signedness in skb remaining space calculationSyzkaller 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, thekernel will attempt to append the new data to that skb. However, the codethat 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: intskb->len: unsigned int'''Due to C's type promotion rules, the signed size_goal is converted to anunsigned int to match skb->len before the subtraction. The result is anunsigned int.When this unsigned int result is then assigned to the s64 copy variable,it is zero-extended, preserving its non-negative value. Consequently, copyis always >= 0.Assume we are sending 2GB of data and size_goal has been adjusted to avalue smaller than skb->len. The subtraction will result in copy holding avery large positive integer. In the subsequent logic, this large value isused to update sk->sk_forward_alloc, which can easily cause it to overflow.The syzkaller reproducer uses TCP_REPAIR to reliably create thiscondition. However, this can also occur in real-world scenarios. Thetcp_bound_to_half_wnd() function can also reduce size_goal to a smallvalue. This would cause the subsequent tcp_wmem_schedule() to setsk->sk_forward_alloc to a value close to INT_MAX. Further memoryallocation requests would then cause sk_forward_alloc to wrap around andbecome negative.[1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38531 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:iio: common: st_sensors: Fix use of uninitialize device structsThroughout the various probe functions &indio_dev->dev is used before itis initialized. This caused a kernel panic in st_sensors_power_enable()when the call to devm_regulator_bulk_get_enable() fails and then callsdev_err_probe() with the uninitialized device.This seems to only cause a panic with dev_err_probe(), dev_err(),dev_warn() and dev_info() don't seem to cause a panic, but are fixedas well.The issue is reported and traced here: [1]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38533 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: libwx: fix the using of Rx buffer DMAThe wx_rx_buffer structure contained two DMA address fields: 'dma' and'page_dma'. However, only 'page_dma' was actually initialized and usedto program the Rx descriptor. But 'dma' was uninitialized and used insome paths.This could lead to undefined behavior, including DMA errors oruse-after-free, if the uninitialized 'dma' was used. Althrough sucherror has not yet occurred, it is worth fixing in the code.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38542 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: appletalk: Fix device refcount leak in atrtr_create()When updating an existing route entry in atrtr_create(), the old devicereference was not being released before assigning the new device,leading to a device refcount leak. Fix this by calling dev_put() torelease the old device reference before holding the new one.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38545 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: ti: am65-cpsw-nuss: Fix skb size by accounting for skb_shared_infoWhile transitioning from netdev_alloc_ip_align() to build_skb(), memoryfor the "skb_shared_info" member of an "skb" was not allocated. Fix thisby allocating "PAGE_SIZE" as the skb length, accounting for the packetlength, headroom and tailroom, thereby including the required memory spacefor skb_shared_info.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38568 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: mqprio: fix stack out-of-bounds write in tc entry parsingTCA_MQPRIO_TC_ENTRY_INDEX is validated usingNLA_POLICY_MAX(NLA_U32, TC_QOPT_MAX_QUEUE), which allows the valueTC_QOPT_MAX_QUEUE (16). This leads to a 4-byte out-of-bounds stackwrite in the fp[] array, which only has room for 16 elements (0-15).Fix this by changing the policy to allow only up to TC_QOPT_MAX_QUEUE - 1.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38582 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix double destruction of rsv_qprsv_qp may be double destroyed in error flow, first in free_mr_init(),and then in hns_roce_exit(). Fix it by moving the free_mr_init() callinto hns_roce_v2_init().list_del corruption, ffff589732eb9b50->next is LIST_POISON1 (dead000000000100)WARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240...Call trace: __list_del_entry_valid+0x148/0x240 hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2] hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2] hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2] free_mr_exit+0x6c/0x120 [hns_roce_hw_v2] hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2] hns_roce_exit+0x118/0x350 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2] hclge_notify_roce_client+0x6c/0x160 [hclge] hclge_reset_rebuild+0x150/0x5c0 [hclge] hclge_reset+0x10c/0x140 [hclge] hclge_reset_subtask+0x80/0x104 [hclge] hclge_reset_service_task+0x168/0x3ac [hclge] hclge_service_task+0x50/0x100 [hclge] process_one_work+0x250/0x9a0 worker_thread+0x324/0x990 kthread+0x190/0x210 ret_from_fork+0x10/0x18

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38639 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_nfacct: don't assume acct name is null-terminatedBUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851[..] string+0x231/0x2b0 lib/vsprintf.c:721 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874 [..] nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523nfnl_acct_find_get() handles non-null input, but the errorprintk relied on its presence.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38648 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:spi: stm32: Check for cfg availability in stm32_spi_probeThe stm32_spi_probe function now includes a check to ensure that thepointer returned by of_device_get_match_data is not NULL beforeaccessing its members. This resolves a warning where a potential NULLpointer dereference could occur when accessing cfg->has_device_mode.Before accessing the 'has_device_mode' member, we verify that 'cfg' isnot NULL. If 'cfg' is NULL, an error message is logged.This change ensures that the driver does not attempt to accessconfiguration data if it is not available, thus preventing a potentialsystem crash due to a NULL pointer dereference.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39716 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:parisc: Revise __get_user() to probe user read accessBecause of the way read access support is implemented, read accessinterruptions are only triggered at privilege levels 2 and 3. Thekernel executes at privilege level 0, so __get_user() never triggersa read access interruption (code 26). Thus, it is currently possiblefor user code to access a read protected address via a system call.Fix this by probing read access rights at privilege level 3 (PRIV_USER)and setting __gu_err to -EFAULT (-14) if access isn't allowed.Note the cmpiclr instruction does a 32-bit compare because COND macrodoesn't work inside asm.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39791 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:dm: dm-crypt: Do not partially accept write BIOs with zoned targetsRead and write operations issued to a dm-crypt target may be splitaccording to the dm-crypt internal limits defined by the max_read_sizeand max_write_size module parameters (default is 128 KB). The intent isto improve processing time of large BIOs by splitting them into smalleroperations that can be parallelized on different CPUs.For zoned dm-crypt targets, this BIO splitting is still done but withoutthe parallel execution to ensure that the issuing order of writeoperations to the underlying devices remains sequential. However, thesplitting itself causes other problems:1) Since dm-crypt relies on the block layer zone write plugging to handle zone append emulation using regular write operations, the reminder of a split write BIO will always be plugged into the target zone write plugged. Once the on-going write BIO finishes, this reminder BIO is unplugged and issued from the zone write plug work. If this reminder BIO itself needs to be split, the reminder will be re-issued and plugged again, but that causes a call to a blk_queue_enter(), which may block if a queue freeze operation was initiated. This results in a deadlock as DM submission still holds BIOs that the queue freeze side is waiting for.2) dm-crypt relies on the emulation done by the block layer using regular write operations for processing zone append operations. This still requires to properly return the written sector as the BIO sector of the original BIO. However, this can be done correctly only and only if there is a single clone BIO used for processing the original zone append operation issued by the user. If the size of a zone append operation is larger than dm-crypt max_write_size, then the orginal BIO will be split and processed as a chain of regular write operations. Such chaining result in an incorrect written sector being returned to the zone append issuer using the original BIO sector. This in turn results in file system data corruptions using xfs or btrfs.Fix this by modifying get_max_request_size() to always return the sizeof the BIO to avoid it being split with dm_accpet_partial_bio() incrypt_map(). get_max_request_size() is renamed toget_max_request_sectors() to clarify the unit of the value returnedand its interface is changed to take a struct dm_target pointer and apointer to the struct bio being processed. In addition to this change,to ensure that crypt_alloc_buffer() works correctly, set the dm-cryptdevice max_hw_sectors limit to be at mostBIO_MAX_VECS << PAGE_SECTORS_SHIFT (1 MB with a 4KB page architecture).This forces DM core to split write BIOs before passing them tocrypt_map(), and thus guaranteeing that dm-crypt can always accept anentire write BIO without needing to split it.This change does not have any effect on the read path of dm-crypt. Readoperations can still be split and the BIO fragments processed inparallel. There is also no impact on the performance of the write pathgiven that all zone write BIOs were already processed inline instead ofin parallel.This change also does not affect in any way regular dm-crypt blockdevices.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39923 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/eesWhen we don't have a clock specified in the device tree, we have no way toensure the BAM is on. This is often the case for remotely-controlled orremotely-powered BAM instances. In this case, we need to read num-channelsfrom the DT to have all the necessary information to complete probing.However, at the moment invalid device trees without clock and withoutnum-channels still continue probing, because the error handling is missingreturn statements. The driver will then later try to read the number ofchannels from the registers. This is unsafe, because it relies on bootfirmware and lucky timing to succeed. Unfortunately, the lack of propererror handling here has been abused for several Qualcomm SoCs upstream,causing early boot crashes in several situations [1, 2].Avoid these early crashes by erroring out when any of the required DTproperties are missing. Note that this will break some of the existing DTsupstream (mainly BAM instances related to the crypto engine). However,clearly these DTs have never been tested properly, since the error in thekernel log was just ignored. It's safer to disable the crypto engine forthese broken DTBs.[1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/[2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39949 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:qed: Don't collect too many protection override GRC elementsIn the protection override dump path, the firmware can return far toomany GRC elements, resulting in attempting to write past the end of thepreviously-kmalloc'ed dump buffer.This will result in a kernel panic with reason: BUG: unable to handle kernel paging request at ADDRESSwhere "ADDRESS" is just past the end of the protection override dumpbuffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_bufand the size of the buffer is buf_size in the same data structure.The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663Resolve this by clamping the firmware's return value to the maximumnumber of legal elements the firmware should return.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39955 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rskin the TCP_ESTABLISHED state. [0]syzbot reused the server-side TCP Fast Open socket as a new client beforethe TFO socket completes 3WHS: 1. accept() 2. connect(AF_UNSPEC) 3. connect() to another destinationAs of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changesit to TCP_CLOSE and makes connect() possible, which restarts timers.Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, theretransmit timer triggered the warning and the intended packet was notretransmitted.Let's call reqsk_fastopen_remove() in tcp_disconnect().[0]:WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))Modules linked in:CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3eRSP: 0018:ffffc900002f8d40 EFLAGS: 00010293RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0Call Trace: tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1)) tmigr_handle_remote (kernel/time/timer_migration.c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39956 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:igc: don't fail igc_probe() on LED setup errorWhen igc_led_setup() fails, igc_probe() fails and triggers kernel panicin free_netdev() since unregister_netdev() is not called. [1]This behavior can be tested using fault-injection framework, especiallythe failslab feature. [2]Since LED support is not mandatory, treat LED setup failures asnon-fatal and continue probe with a warning message, consequentlyavoiding the kernel panic.[1] kernel BUG at net/core/dev.c:12047! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:free_netdev+0x278/0x2b0 [...] Call Trace: igc_probe+0x370/0x910 local_pci_probe+0x3a/0x80 pci_device_probe+0xd1/0x200 [...][2] #!/bin/bash -ex FAILSLAB_PATH=/sys/kernel/debug/failslab/ DEVICE=0000:00:05.0 START_ADDR=$(grep " igc_led_setup" /proc/kallsyms \ | awk '{printf("0x%s", $1)}') END_ADDR=$(printf "0x%x" $((START_ADDR + 0x100))) echo $START_ADDR > $FAILSLAB_PATH/require-start echo $END_ADDR > $FAILSLAB_PATH/require-end echo 1 > $FAILSLAB_PATH/times echo 100 > $FAILSLAB_PATH/probability echo N > $FAILSLAB_PATH/ignore-gfp-wait echo $DEVICE > /sys/bus/pci/drivers/igc/bind

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39967 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: fix integer overflow in fbcon_do_set_fontFix integer overflow vulnerabilities in fbcon_do_set_font() where fontsize calculations could overflow when handling user-controlled fontparameters.The vulnerabilities occur when:1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow.2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow3. This results in smaller allocations than expected, leading to buffer overflows during font data copying.Add explicit overflow checking using check_mul_overflow() andcheck_add_overflow() kernel helpers to safety validate all sizecalculations before allocation.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39970 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix input validation logic for action_metaFix condition to check 'greater or equal' to prevent OOB dereference.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39972 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix idx validation in i40e_validate_queue_mapEnsure idx is within range of active/initialized TCs when iterating overvf->ch[idx] in i40e_validate_queue_map().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39998 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: target_core_configfs: Add length check to avoid buffer overflowA buffer overflow arises from the usage of snprintf to write into thebuffer "buf" in target_lu_gp_members_show function located in/drivers/target/target_core_configfs.c. This buffer is allocated withsize LU_GROUP_NAME_BUF (256 bytes).snprintf(...) formats multiple strings into buf with the HBA name(hba->hba_group.cg_item), a slash character, a devicename (dev->dev_group.cg_item) and a newline character, the total formatted stringlength may exceed the buffer size of 256 bytes.Since snprintf() returns the total number of bytes that would have beenwritten (the length of %s/%sn ), this value may exceed the buffer length(256 bytes) passed to memcpy(), this will ultimately cause functionmemcpy reporting a buffer overflow error.An additional check of the return value of snprintf() can avoid thisbuffer overflow.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40020 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:can: peak_usb: fix shift-out-of-bounds issueExplicitly uses a 64-bit constant when the number of bits used for itsshifting is 32 (which is the case for PC CAN FD interfaces supported bythis driver).[mkl: update subject, apply manually]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40049 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: fix uninit-value in squashfs_get_parentSyzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.This is caused by open_by_handle_at() being called with a file handlecontaining an invalid parent inode number. In particular the inode numberis that of a symbolic link, rather than a directory.Squashfs_get_parent() gets called with that symbolic link inode, andaccesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent;Because non-directory inodes in Squashfs do not have a parent value, thisis uninitialised, and this causes an uninitialised value access.The fix is to initialise parent with the invalid inode 0, which will causean EINVAL error to be returned.Regular inodes used to share the parent field with the block_list_startfield. This is removed in this commit to enable the parent field tocontain the invalid inode number 0.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40056 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:vhost: vringh: Fix copy_to_iter return value checkThe return value of copy_to_iter can't be negative, check whether thecopied length is equal to the requested length instead of checking fornegative values.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40085 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix NULL pointer deference in try_to_register_cardIn try_to_register_card(), the return value of usb_ifnum_to_if() ispassed directly to usb_interface_claimed() without a NULL check, whichwill lead to a NULL pointer dereference when creating an invalidUSB audio device. Fix this by adding a check to ensure the interfacepointer is valid before passing it to usb_interface_claimed().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40086 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: Don't allow evicting of BOs in same VM in array of VM bindsAn array of VM binds can potentially evict other buffer objects (BOs)within the same VM under certain conditions, which may lead to NULLpointer dereferences later in the bind pipeline. To prevent this, clearthe allow_res_evict flag in the xe_bo_validate call.v2: - Invert polarity of no_res_evict (Thomas) - Add comment in code explaining issue (Thomas)(cherry picked from commit 8b9ba8d6d95fe75fed6b0480bb03da4b321bea08)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40118 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Fix array-index-out-of-of-bounds on rmmodSince commit f7b705c238d1 ("scsi: pm80xx: Set phy_attached to zero whendevice is gone") UBSAN reports: UBSAN: array-index-out-of-bounds in drivers/scsi/pm8001/pm8001_sas.c:786:17 index 28 is out of range for type 'pm8001_phy [16]'on rmmod when using an expander.For a direct attached device, attached_phy contains the local phy id.For a device behind an expander, attached_phy contains the remote phyid, not the local phy id.I.e. while pm8001_ha will have pm8001_ha->chip->n_phy local phys, for adevice behind an expander, attached_phy can be much larger thanpm8001_ha->chip->n_phy (depending on the amount of phys of theexpander).E.g. on my system pm8001_ha has 8 phys with phy ids 0-7. One of theports has an expander connected. The expander has 31 phys with phy ids0-30.The pm8001_ha->phy array only contains the phys of the HBA. It does notcontain the phys of the expander. Thus, it is wrong to use attached_phyto index the pm8001_ha->phy array for a device behind an expander.Thus, we can only clear phy_attached for devices that are directlyattached.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40126 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARCThe referenced commit introduced exception handlers on user-space memoryreferences in copy_from_user and copy_to_user. These handlers return fromthe respective function and calculate the remaining bytes left to copyusing the current register contents. This commit fixes a couple of badcalculations. This will fix the return value of copy_from_user andcopy_to_user in the faulting case. The behaviour of memcpy stays unchanged.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40135 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_xmit()Use RCU in ip6_xmit() in order to use dst_dev_rcu() to preventpossible UAF.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40161 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:mailbox: zynqmp-ipi: Fix SGI cleanup on unbindThe driver incorrectly determines SGI vs SPI interrupts by checking IRQnumber < 16, which fails with dynamic IRQ allocation. During unbind,this causes improper SGI cleanup leading to kernel crash.Add explicit irq_type field to pdata for reliable identification of SGIinterrupts (type-2) and only clean up SGI resources when appropriate.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40190 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: guard against EA inode refcount underflow in xattr updatesyzkaller found a path where ext4_xattr_inode_update_ref() reads an EAinode refcount that is already <= 0 and then applies ref_change (often-1). That lets the refcount underflow and we proceed with a bogus value,triggering errors like: EXT4-fs error: EA inode ref underflow: ref_count=-1 ref_change=-1 EXT4-fs warning: ea_inode dec ref err=-117Make the invariant explicit: if the current refcount is non-positive,treat this as on-disk corruption, emit ext4_error_inode(), and fail theoperation with -EFSCORRUPTED instead of updating the refcount. Delete theWARN_ONCE() as negative refcounts are now impossible; keep error reportingin ext4_error_inode().This prevents the underflow and the follow-on orphan/cleanup churn.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40213 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: fix crash in set_mesh_sync and set_mesh_completeThere is a BUG: KASAN: stack-out-of-bounds in set_mesh_sync due tomemcpy from badly declared on-stack flexible array.Another crash is in set_mesh_complete() due to double list_del viamgmt_pending_valid + mgmt_pending_remove.Use DEFINE_FLEX to declare the flexible array right, and don't memcpyoutside bounds.As mgmt_pending_valid removes the cmd from list, use mgmt_pending_free,and also report status on error.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40220 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:fuse: fix livelock in synchronous file put from fuseblk workersI observed a hang when running generic/323 against a fuseblk server.This test opens a file, initiates a lot of AIO writes to that filedescriptor, and closes the file descriptor before the writes complete.Unsurprisingly, the AIO exerciser threads are mostly stuck waiting forresponses from the fuseblk server:# cat /proc/372265/task/372313/stack[<0>] request_wait_answer+0x1fe/0x2a0 [fuse][<0>] __fuse_simple_request+0xd3/0x2b0 [fuse][<0>] fuse_do_getattr+0xfc/0x1f0 [fuse][<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse][<0>] aio_read+0x130/0x1e0[<0>] io_submit_one+0x542/0x860[<0>] __x64_sys_io_submit+0x98/0x1a0[<0>] do_syscall_64+0x37/0xf0[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53But the /weird/ part is that the fuseblk server threads are waiting forresponses from itself:# cat /proc/372210/task/372232/stack[<0>] request_wait_answer+0x1fe/0x2a0 [fuse][<0>] __fuse_simple_request+0xd3/0x2b0 [fuse][<0>] fuse_file_put+0x9a/0xd0 [fuse][<0>] fuse_release+0x36/0x50 [fuse][<0>] __fput+0xec/0x2b0[<0>] task_work_run+0x55/0x90[<0>] syscall_exit_to_user_mode+0xe9/0x100[<0>] do_syscall_64+0x43/0xf0[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53The fuseblk server is fuse2fs so there's nothing all that exciting inthe server itself. So why is the fuse server calling fuse_file_put?The commit message for the fstest sheds some light on that:"By closing the file descriptor before calling io_destroy, you prettymuch guarantee that the last put on the ioctx will be done in interruptcontext (during I/O completion).Aha. AIO fgets a new struct file from the fd when it queues the ioctx.The completion of the FUSE_WRITE command from userspace causes the fuseserver to call the AIO completion function. The completion puts thestruct file, queuing a delayed fput to the fuse server task. When thefuse server task returns to userspace, it has to run the delayed fput,which in the case of a fuseblk server, it does synchronously.Sending the FUSE_RELEASE command sychronously from fuse server threadsis a bad idea because a client program can initiate enough simultaneousAIOs such that all the fuse server threads end up in delayed_fput, andnow there aren't any threads left to handle the queued fuse commands.Fix this by only using asynchronous fputs when closing files, and leavea comment explaining why.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40314 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadgetIn the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadgetstructure (pdev->gadget) was freed before its endpoints.The endpoints are linked via the ep_list in the gadget structure.Freeing the gadget first leaves dangling pointers in the endpoint list.When the endpoints are subsequently freed, this results in a use-after-free.Fix:By separating the usb_del_gadget_udc() operation into distinct "del" and"put" steps, cdnsp_gadget_free_endpoints() can be executed prior to thefinal release of the gadget structure with usb_put_gadget().A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure only after freeing endpoints").

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40357 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix general protection fault in __smc_diag_dumpThe syzbot report a crash: Oops: general protection fault, probably for non-canonical address 0xfbd5a5d5a0000003: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead4ead00000018-0xdead4ead0000001f] CPU: 1 UID: 0 PID: 6949 Comm: syz.0.335 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:smc_diag_msg_common_fill net/smc/smc_diag.c:44 [inline] RIP: 0010:__smc_diag_dump.constprop.0+0x3ca/0x2550 net/smc/smc_diag.c:89 Call Trace: smc_diag_dump_proto+0x26d/0x420 net/smc/smc_diag.c:217 smc_diag_dump+0x27/0x90 net/smc/smc_diag.c:234 netlink_dump+0x539/0xd30 net/netlink/af_netlink.c:2327 __netlink_dump_start+0x6d6/0x990 net/netlink/af_netlink.c:2442 netlink_dump_start include/linux/netlink.h:341 [inline] smc_diag_handler_dump+0x1f9/0x240 net/smc/smc_diag.c:251 __sock_diag_cmd net/core/sock_diag.c:249 [inline] sock_diag_rcv_msg+0x438/0x790 net/core/sock_diag.c:285 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5a7/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg net/socket.c:729 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2614 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2668 __sys_sendmsg+0x16d/0x220 net/socket.c:2700 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The process like this: (CPU1) | (CPU2) ---------------------------------|------------------------------- inet_create() | // init clcsock to NULL | sk = sk_alloc() | | // unexpectedly change clcsock | inet_init_csk_locks() | | // add sk to hash table | smc_inet_init_sock() | smc_sk_init() | smc_hash_sk() | | // traverse the hash table | smc_diag_dump_proto | __smc_diag_dump() | // visit wrong clcsock | smc_diag_msg_common_fill() // alloc clcsock | smc_create_clcsk | sock_create_kern |With CONFIG_DEBUG_LOCK_ALLOC=y, the smc->clcsock is unexpectedly changedin inet_init_csk_locks(). The INET_PROTOSW_ICSK flag is no need by smc,just remove it.After removing the INET_PROTOSW_ICSK flag, this patch alse revertcommit 6fd27ea183c2 ("net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC")to avoid casting smc_sock to inet_connection_sock.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-58050 Severity: Moderate CVSS3 score: 6.1

Description: The PCRE2 library is a set of C functions that implement regular expression pattern matching. In version 10.45, a heap-buffer-overflow read vulnerability exists in the PCRE2 regular expression matching engine, specifically within the handling of the (*scs:...) (Scan SubString) verb when combined with (*ACCEPT) in src/pcre2_match.c. This vulnerability may potentially lead to information disclosure if the out-of-bounds data read during the memcmp affects the final match result in a way observable by the attacker. This issue has been resolved in version 10.46.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpcre2-16-0 > 0-0 (version in image is 10.45-160000.2.2).

CVE-2025-68183 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattrCurrently when both IMA and EVM are in fix mode, the IMA signature willbe reset to IMA hash if a program first stores IMA signature insecurity.ima and then writes/removes some other security xattr for thefile.For example, on Fedora, after booting the kernel with "ima_appraise=fixevm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima,installing/reinstalling a package will not make good reference IMAsignature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404...This happens because when setting security.selinux, the IMA_DIGSIG flagthat had been set early was cleared. As a result, IMA hash is generatedwhen the file is closed.Similarly, IMA signature can be cleared on file close after removingsecurity xattr like security.evm or setting/removing ACL.Prevent replacing the IMA file signature with a file hash, by preventingthe IMA_DIGSIG flag from being reset.Here's a minimal C reproducer which sets security.selinux as the laststep which can also replaced by removing security.evm or setting ACL, #include #include #include #include #include #include int main() { const char* file_path = "/usr/sbin/test_binary"; const char* hex_string = "030204d33204490066306402304"; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror("Error opening file"); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]); } if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } const char* selinux_value= "system_u:object_r:bin_t:s0"; if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } close(fd); return 0; }

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68313 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:x86/CPU/AMD: Add RDSEED fix for Zen5There's an issue with RDSEED's 16-bit and 32-bit register outputvariants on Zen5 which return a random value of 0 "at a rate inconsistentwith randomness while incorrectly signaling success (CF=1)". Search theweb for AMD-SB-7055 for more detail.Add a fix glue which checks microcode revisions. [ bp: Add microcode revisions checking, rewrite. ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68328 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: stratix10-svc: fix bug in saving controller dataFix the incorrect usage of platform_set_drvdata and dev_set_drvdata. Theyboth are of the same data and overrides each other. This resulted in thermmod of the svc driver to fail and throw a kernel panic for kthread_stopand fifo free.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68342 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing dataThe URB received in gs_usb_receive_bulk_callback() contains a structgs_host_frame. The length of the data after the header depends on thegs_host_frame hf::flags and the active device features (e.g. timestamping).Introduce a new function gs_usb_get_minimum_length() and check that we haveat least received the required amount of data before accessing it. Onlycopy the data to that skb that has actually been received.[mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68343 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing headerThe driver expects to receive a struct gs_host_frame ings_usb_receive_bulk_callback().Use struct_group to describe the header of the struct gs_host_frame andcheck that we have at least received the header before accessing anymembers of it.To resubmit the URB, do not dereference the pointer chain"dev->parent->hf_size_rx" but use "parent->hf_size_rx" instead. Since"urb->context" contains "parent", it is always defined, while "dev" is notdefined if the URB it too short.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68347 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP eventsThe DSP event handling code in hwdep_read() could write more bytes tothe user buffer than requested, when a user provides a buffer smallerthan the event header size (8 bytes).Fix by using min_t() to clamp the copy size, This ensures we never copymore than the user requested.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68758 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:backlight: led-bl: Add devlink to supplier LEDsLED Backlight is a consumer of one or multiple LED class devices, butdevlink is currently unable to create correct supplier-producer links whenthe supplier is a class device. It creates instead a link where thesupplier is the parent of the expected device.One consequence is that removal order is not correctly enforced.Issues happen for example with the following sections in a device treeoverlay: // An LED driver chip pca9632@62 { compatible = "nxp,pca9632"; reg = <0x62>; // ... addon_led_pwm: led-pwm@3 { reg = <3>; label = "addon:led:pwm"; }; }; backlight-addon { compatible = "led-backlight"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; };In this example, the devlink should be created between the backlight-addon(consumer) and the pca9632@62 (supplier). Instead it is created between thebacklight-addon (consumer) and the parent of the pca9632@62, which istypically the I2C bus adapter.On removal of the above overlay, the LED driver can be removed before thebacklight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98Another way to reproduce the bug without any device tree overlays isunbinding the LED class device (pca9632@62) before unbinding the consumer(backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbindFix by adding a devlink between the consuming led-backlight device and thesupplying LED device, as other drivers and subsystems do as well.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-71114 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:via_wdt: fix critical boot hang due to unnamed resource allocationThe VIA watchdog driver uses allocate_resource() to reserve a MMIOregion for the watchdog control register. However, the allocatedresource was not given a name, which causes the kernel resource treeto contain an entry marked as "" under /proc/iomem on x86platforms.During boot, this unnamed resource can lead to a critical hang becausesubsequent resource lookups and conflict checks fail to handle theinvalid entry properly.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-7545 Severity: Moderate CVSS3 score: 6.1

Description: A vulnerability classified as problematic was found in GNU Binutils 2.45. Affected by this vulnerability is the function copy_section of the file binutils/objcopy.c. The manipulation leads to heap-based buffer overflow. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The patch is named 08c3cbe5926e4d355b5cb70bbec2b1eeb40c2944. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-7546 Severity: Moderate CVSS3 score: 6.1

Description: A vulnerability, which was classified as problematic, has been found in GNU Binutils 2.45. Affected by this issue is the function bfd_elf_set_group_contents of the file bfd/elf.c. The manipulation leads to out-of-bounds write. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The name of the patch is 41461010eb7c79fee7a9d5f6209accdaac66cc6b. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2026-22695 Severity: Moderate CVSS3 score: 6.1

Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.51 to 1.6.53, there is a heap buffer over-read in the libpng simplified API function png_image_finish_read when processing interlaced 16-bit PNGs with 8-bit output format and non-minimal row stride. This is a regression introduced by the fix for CVE-2025-65018. This vulnerability is fixed in 1.6.54.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpng16-16 < 1.6.44-160000.4.1 (version in image is 1.6.44-160000.2.2).

CVE-2026-22977 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: sock: fix hardened usercopy panic in sock_recv_errqueueskbuff_fclone_cache was created without defining a usercopy region,[1] unlike skbuff_head_cache which properly whitelists the cb[] field.[2] This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY isenabled and the kernel attempts to copy sk_buff.cb data to userspacevia sock_recv_errqueue() -> put_cmsg().The crash occurs when: 1. TCP allocates an skb using alloc_skb_fclone() (from skbuff_fclone_cache) [1]2. The skb is cloned via skb_clone() using the pre-allocated fclone[3] 3. The cloned skb is queued to sk_error_queue for timestampreporting 4. Userspace reads the error queue via recvmsg(MSG_ERRQUEUE)5. sock_recv_errqueue() calls put_cmsg() to copy serr->ee from skb->cb[4] 6. __check_heap_object() fails because skbuff_fclone_cache has no usercopy whitelist [5]When cloned skbs allocated from skbuff_fclone_cache are used in thesocket error queue, accessing the sock_exterr_skb structure in skb->cbvia put_cmsg() triggers a usercopy hardening violation:[ 5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache' (offset 296, size 16)![ 5.382796] kernel BUG at mm/usercopy.c:102![ 5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI[ 5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7[ 5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 5.384903] RIP: 0010:usercopy_abort+0x6c/0x80[ 5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff <0f> 0b 490[ 5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246[ 5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74[ 5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0[ 5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74[ 5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001[ 5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00[ 5.384903] FS: 0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000[ 5.384903] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0[ 5.384903] PKRU: 55555554[ 5.384903] Call Trace:[ 5.384903] [ 5.384903] __check_heap_object+0x9a/0xd0[ 5.384903] __check_object_size+0x46c/0x690[ 5.384903] put_cmsg+0x129/0x5e0[ 5.384903] sock_recv_errqueue+0x22f/0x380[ 5.384903] tls_sw_recvmsg+0x7ed/0x1960[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5[ 5.384903] ? schedule+0x6d/0x270[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5[ 5.384903] ? mutex_unlock+0x81/0xd0[ 5.384903] ? __pfx_mutex_unlock+0x10/0x10[ 5.384903] ? __pfx_tls_sw_recvmsg+0x10/0x10[ 5.384903] ? _raw_spin_lock_irqsave+0x8f/0xf0[ 5.384903] ? _raw_read_unlock_irqrestore+0x20/0x40[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5The crash offset 296 corresponds to skb2->cb within skbuff_fclones: - sizeof(struct sk_buff) = 232 - offsetof(struct sk_buff, cb) = 40 - offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 = 272 + 24 (inside sock_exterr_skb.ee)This patch uses a local stack variable as a bounce buffer to avoid the hardened usercopy check failure.[1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885[2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104[3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566[4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491[5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23005 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD inresponse to a guest WRMSR, clear XFD-disabled features in the saved (or tobe restored) XSTATE_BV to ensure KVM doesn't attempt to load state forfeatures that are disabled via the guest's XFD. Because the kernelexecutes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1will cause XRSTOR to #NM and panic the kernel.E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848 Modules linked in: kvm_intel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 switch_fpu_return+0x4a/0xb0 kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]---This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1,and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler'scall to fpu_update_guest_xfd().and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867 Modules linked in: kvm_intel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 fpu_swap_kvm_fpstate+0x6b/0x120 kvm_load_guest_fpu+0x30/0x80 [kvm] kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]---The new behavior is consistent with the AMX architecture. Per Intel's SDM,XSAVE saves XSTATE_BV as '0' for components that are disabled via XFD(and non-compacted XSAVE saves the initial configuration of the statecomponent): If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was in its initial state): it saves bit i of XSTATE_BV field of the XSAVE header as 0; in addition, XSAVE saves the initial configuration of the state component (the other instructions do not save state component i).Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by usinga constant XFD based on the set of enabled features when XSAVEing fora struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabledfeatures can only happen in the above interrupt case, or in similarscenarios involving preemption on preemptible kernels, becausefpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves theoutgoing FPU state with the current XFD; and that is (on all but thefirst WRMSR to XFD) the guest XFD.Therefore, XFD can only go out of sync with XSTATE_BV in the aboveinterrupt case, or in similar scenarios involving preemption onpreemptible kernels, and it we can consider it (de facto) part of KVMABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.[Move clea---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23010 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix use-after-free in inet6_addr_del().syzbot reported use-after-free of inet6_ifaddr ininet6_addr_del(). [0]The cited commit accidentally moved ipv6_del_addr() formngtmpaddr before reading its ifp->flags for temporaryaddresses in inet6_addr_del().Let's move ipv6_del_addr() down to fix the UAF.[0]:BUG: KASAN: slab-use-after-free in inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117Read of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593CPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Call Trace: __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:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 addrconf_del_ifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181 inet6_ioctl+0x1e5/0x2b0 net/ipv6/af_inet6.c:582 sock_do_ioctl+0x118/0x280 net/socket.c:1254 sock_ioctl+0x227/0x6b0 net/socket.c:1375 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f164cf8f749Code: 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 48RSP: 002b:00007f164de64038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749RDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003RBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288 Allocated by task 9593: kasan_save_stack+0x33/0x60 mm/kasan/common.c:56 kasan_save_track+0x14/0x30 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:397 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:414 kmalloc_noprof include/linux/slab.h:957 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] ipv6_add_addr+0x4e3/0x2010 net/ipv6/addrconf.c:1120 inet6_addr_add+0x256/0x9b0 net/ipv6/addrconf.c:3050 addrconf_add_ifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160 inet6_ioctl+0x103/0x2b0 net/ipv6/af_inet6.c:580 sock_do_ioctl+0x118/0x280 net/socket.c:1254 sock_ioctl+0x227/0x6b0 net/socket.c:1375 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 6099: kasan_save_stack+0x33/0x60 mm/kasan/common.c:56 kasan_save_track+0x14/0x30 mm/kasan/common.c:77 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:252 [inline] __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284 kasan_slab_free include/linux/kasan.h:234 [inline] slab_free_hook mm/slub.c:2540 [inline] slab_free_freelist_hook mm/slub.c:2569 [inline] slab_free_bulk mm/slub.c:6696 [inline] kmem_cache_free_bulk mm/slub.c:7383 [inline] kmem_cache_free_bulk+0x2bf/0x680 mm/slub.c:7362 kfree_bulk include/linux/slab.h:830 [inline] kvfree_rcu_bulk+0x1b7/0x1e0 mm/slab_common.c:1523 kvfree_rcu_drain_ready mm/slab_common.c:1728 [inline] kfree_rcu_monitor+0x1d0/0x2f0 mm/slab_common.c:1801 process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257 process_scheduled_works kernel/workqu---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38702 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: fix potential buffer overflow in do_register_framebuffer()The current implementation may lead to buffer overflow when:1. Unregistration creates NULL gaps in registered_fb[]2. All array slots become occupied despite num_registered_fb < FB_MAX3. The registration loop exceeds array boundsAdd boundary check to prevent registered_fb[FB_MAX] access.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39691 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:fs/buffer: fix use-after-free when call bh_read() helperThere's issue as follows:BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)Call Trace: dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x2c/0x390 print_report+0xb4/0x270 kasan_report+0xb8/0xf0 end_buffer_read_sync+0xe3/0x110 end_bio_bh_io_sync+0x56/0x80 blk_update_request+0x30a/0x720 scsi_end_request+0x51/0x2b0 scsi_io_completion+0xe3/0x480 ? scsi_device_unbusy+0x11e/0x160 blk_complete_reqs+0x7b/0x90 handle_softirqs+0xef/0x370 irq_exit_rcu+0xa5/0xd0 sysvec_apic_timer_interrupt+0x6e/0x90 Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQntfs_fill_super read_cache_page do_read_cache_folio filemap_read_folio mpage_read_folio do_mpage_readpage ntfs_get_block_vbo bh_read submit_bh wait_on_buffer(bh); blk_complete_reqs scsi_io_completion scsi_end_request blk_update_request end_bio_bh_io_sync end_buffer_read_sync __end_buffer_read_notouch unlock_buffer wait_on_buffer(bh);--> return will return to caller put_bh --> trigger stack-out-of-boundsIn the mpage_read_folio() function, the stack variable 'map_bh' ispassed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks andwait_on_buffer() returns to continue processing, the stack variableis likely to be reclaimed. Consequently, during the end_buffer_read_sync()process, calling put_bh() may result in stack overrun.If the bh is not allocated on the stack, it belongs to a folio. Freeinga buffer head which belongs to a folio is done by drop_buffers() whichwill fail to free buffers which are still locked. So it is safe to callput_bh() before __end_buffer_read_notouch().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40292 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:virtio-net: fix received length check in big packetsSince commit 4959aebba8c0 ("virtio-net: use mtu size as buffer lengthfor big packets"), when guest gso is off, the allocated size for bigpackets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends onnegotiated MTU. The number of allocated frags for big packets is storedin vi->big_packets_num_skbfrags.Because the host announced buffer length can be malicious (e.g. the hostvhost_net driver's get_rx_bufs is modified to announce incorrectlength), we need a check in virtio_net receive path. Currently, thecheck is not adapted to the new change which can lead to NULL pagepointer dereference in the below while loop when receiving length thatis larger than the allocated one.This commit fixes the received length check corresponding to the newchange.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68208 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: account for current allocated stack depth in widen_imprecise_scalars()The usage pattern for widen_imprecise_scalars() looks as follows: prev_st = find_prev_entry(env, ...); queued_st = push_stack(...); widen_imprecise_scalars(env, prev_st, queued_st);Where prev_st is an ancestor of the queued_st in the explored statestree. This ancestor is not guaranteed to have same allocated stackdepth as queued_st. E.g. in the following case: def main(): for i in 1..2: foo(i) // same callsite, differnt param def foo(i): if i == 1: use 128 bytes of stack iterator based loopHere, for a second 'foo' call prev_st->allocated_stack is 128,while queued_st->allocated_stack is much smaller.widen_imprecise_scalars() needs to take this into account and avoidaccessing bpf_verifier_state->frame[*]->stack out of bounds.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68741 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix improper freeing of purex itemIn qla2xxx_process_purls_iocb(), an item is allocated viaqla27xx_copy_multiple_pkt(), which internally callsqla24xx_alloc_purex_item().The qla24xx_alloc_purex_item() function may return a pre-allocated itemfrom a per-adapter pool for small allocations, instead of dynamicallyallocating memory with kzalloc().An error handling path in qla2xxx_process_purls_iocb() incorrectly useskfree() to release the item. If the item was from the pre-allocatedpool, calling kfree() on it is a bug that can lead to memory corruption.Fix this by using the correct deallocation function,qla24xx_free_purex_item(), which properly handles both dynamicallyallocated and pre-allocated items.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39797 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Duplicate SPI HandlingThe issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPINetlink message, which triggers the kernel function xfrm_alloc_spi().This function is expected to ensure uniqueness of the Security ParameterIndex (SPI) for inbound Security Associations (SAs). However, it canreturn success even when the requested SPI is already in use, leadingto duplicate SPIs assigned to multiple inbound SAs, differentiatedonly by their destination addresses.This behavior causes inconsistencies during SPI lookups for inbound packets.Since the lookup may return an arbitrary SA among those with the same SPI,packet processing can fail, resulting in packet drops.According to RFC 4301 section 4.4.2 , for inbound processing a unicast SAis uniquely identified by the SPI and optionally protocol.Reproducing the Issue Reliably:To consistently reproduce the problem, restrict the available SPI range incharon.conf : spi_min = 0x10000000 spi_max = 0x10000002This limits the system to only 2 usable SPI values.Next, create more than 2 Child SA. each using unique pair of src/dst address.As soon as the 3rd Child SA is initiated, it will be assigned a duplicateSPI, since the SPI pool is already exhausted.With a narrow SPI range, the issue is consistently reproducible.With a broader/default range, it becomes rare and unpredictable.Current implementation:xfrm_spi_hash() lookup function computes hash using daddr, proto, and family.So if two SAs have the same SPI but different destination addresses, thenthey will:a. Hash into different bucketsb. Be stored in different linked lists (byspi + h)c. Not be seen in the same hlist_for_each_entry_rcu() iteration.As a result, the lookup will result in NULL and kernel allows that Duplicate SPIProposed Change:xfrm_state_lookup_spi_proto() does a truly global search - across all states,regardless of hash bucket and matches SPI and proto.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39950 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:net/tcp: Fix a NULL pointer dereference when using TCP-AO with TCP_REPAIRA NULL pointer dereference can occur in tcp_ao_finish_connect() during aconnect() system call on a socket with a TCP-AO key added and TCP_REPAIRenabled.The function is called with skb being NULL and attempts to dereference iton tcp_hdr(skb)->seq without a prior skb validation.Fix this by checking if skb is NULL before dereferencing it.The commentary is taken from bpf_skops_established(), which is also calledin the same flow. Unlike the function being patched,bpf_skops_established() validates the skb before dereferencing it.int main(void){ struct sockaddr_in sockaddr; struct tcp_ao_add tcp_ao; int sk; int one = 1; memset(&sockaddr,'\0',sizeof(sockaddr)); memset(&tcp_ao,'\0',sizeof(tcp_ao)); sk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); sockaddr.sin_family = AF_INET; memcpy(tcp_ao.alg_name,"cmac(aes128)",12); memcpy(tcp_ao.key,"ABCDEFGHABCDEFGH",16); tcp_ao.keylen = 16; memcpy(&tcp_ao.addr,&sockaddr,sizeof(sockaddr)); setsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &tcp_ao, sizeof(tcp_ao)); setsockopt(sk, IPPROTO_TCP, TCP_REPAIR, &one, sizeof(one)); sockaddr.sin_family = AF_INET; sockaddr.sin_port = htobe16(123); inet_aton("127.0.0.1", &sockaddr.sin_addr); connect(sk,(struct sockaddr *)&sockaddr,sizeof(sockaddr));return 0;}$ gcc tcp-ao-nullptr.c -o tcp-ao-nullptr -Wall$ unshare -UrnBUG: kernel NULL pointer dereference, address: 00000000000000b6PGD 1f648d067 P4D 1f648d067 PUD 1982e8067 PMD 0Oops: Oops: 0000 [#1] SMP NOPTIHardware name: VMware, Inc. VMware Virtual Platform/440BX DesktopReference Platform, BIOS 6.00 11/12/2020RIP: 0010:tcp_ao_finish_connect (net/ipv4/tcp_ao.c:1182)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-58436 Severity: Moderate CVSS3 score: 5.9

Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to version 2.4.15, a client that connects to cupsd but sends slow messages, e.g. only one byte per second, delays cupsd as a whole, such that it becomes unusable by other clients. This issue has been patched in version 2.4.15.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
cups-config > 0-0 (version in image is 2.4.11-160000.2.2).

CVE-2025-68768 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:inet: frags: flush pending skbs in fqdir_pre_exit()We have been seeing occasional deadlocks on pernet_ops_rwsem sinceSeptember in NIPA. The stuck task was usually modprobe (often loadinga driver like ipvlan), trying to take the lock as a Writer.lockdep does not track readers for rwsems so the read wasn't obviousfrom the reports.On closer inspection the Reader holding the lock was conntrack loopingforever in nf_conntrack_cleanup_net_list(). Based on past experiencewith occasional NIPA crashes I looked thru the tests which run beforethe crash and noticed that the crash follows ip_defrag.sh. An immediatered flag. Scouring thru (de)fragmentation queues reveals skbs sittingaround, holding conntrack references.The problem is that since conntrack depends on nf_defrag_ipv6,nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first itsnetns exit hooks run _after_ conntrack's netns exit hook.Flush all fragment queue SKBs during fqdir_pre_exit() to releaseconntrack references before conntrack cleanup runs. Also flushthe queues in timer expiry handlers when they discover fqdir->deadis set, in case packet sneaks in while we're running the pre_exitflush.The commit under Fixes is not exactly the culprit, but I thinkpreviously the timer firing would eventually unblock the spinningconntrack.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68770 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix XDP_TX pathFor XDP_TX action in bnxt_rx_xdp(), clearing of the event flags is notcorrect. __bnxt_poll_work() -> bnxt_rx_pkt() -> bnxt_rx_xdp() may belooping within NAPI and some event flags may be set in earlieriterations. In particular, if BNXT_TX_EVENT is set earlier indicatingsome XDP_TX packets are ready and pending, it will be cleared if it isXDP_TX action again. Normally, we will set BNXT_TX_EVENT again when wesuccessfully call __bnxt_xmit_xdp(). But if the TX ring has no moreroom, the flag will not be set. This will cause the TX producer to beahead but the driver will not hit the TX doorbell.For multi-buf XDP_TX, there is no need to clear the event flags and setBNXT_AGG_EVENT. The BNXT_AGG_EVENT flag should have been set earlier inbnxt_rx_pkt().The visible symptom of this is that the RX ring associated with theTX XDP ring will eventually become empty and all packets will be dropped.Because this condition will cause the driver to not refill the RX ringseeing that the TX ring has forever pending XDP_TX packets.The fix is to only clear BNXT_RX_EVENT when we have successfullycalled __bnxt_xmit_xdp().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68776 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:net/hsr: fix NULL pointer dereference in prp_get_untagged_frame()prp_get_untagged_frame() calls __pskb_copy() to create frame->skb_stdbut doesn't check if the allocation failed. If __pskb_copy() returnsNULL, skb_clone() is called with a NULL pointer, causing a crash:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]CPU: 0 UID: 0 PID: 5625 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:skb_clone+0xd7/0x3a0 net/core/skbuff.c:2041Code: 03 42 80 3c 20 00 74 08 4c 89 f7 e8 23 29 05 f9 49 83 3e 00 0f 85 a0 01 00 00 e8 94 dd 9d f8 48 8d 6b 7e 49 89 ee 49 c1 ee 03 <43> 0f b6 04 26 84 c0 0f 85 d1 01 00 00 44 0f b6 7d 00 41 83 e7 0cRSP: 0018:ffffc9000d00f200 EFLAGS: 00010207RAX: ffffffff892235a1 RBX: 0000000000000000 RCX: ffff88803372a480RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000000RBP: 000000000000007e R08: ffffffff8f7d0f77 R09: 1ffffffff1efa1eeR10: dffffc0000000000 R11: fffffbfff1efa1ef R12: dffffc0000000000R13: 0000000000000820 R14: 000000000000000f R15: ffff88805144cc00FS: 0000555557f6d500(0000) GS:ffff88808d72f000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000555581d35808 CR3: 000000005040e000 CR4: 0000000000352ef0Call Trace: hsr_forward_do net/hsr/hsr_forward.c:-1 [inline] hsr_forward_skb+0x1013/0x2860 net/hsr/hsr_forward.c:741 hsr_handle_frame+0x6ce/0xa70 net/hsr/hsr_slave.c:84 __netif_receive_skb_core+0x10b9/0x4380 net/core/dev.c:5966 __netif_receive_skb_one_core net/core/dev.c:6077 [inline] __netif_receive_skb+0x72/0x380 net/core/dev.c:6192 netif_receive_skb_internal net/core/dev.c:6278 [inline] netif_receive_skb+0x1cb/0x790 net/core/dev.c:6337 tun_rx_batched+0x1b9/0x730 drivers/net/tun.c:1485 tun_get_user+0x2b65/0x3e90 drivers/net/tun.c:1953 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 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/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f0449f8e1ffCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 f9 92 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 4c 93 02 00 48RSP: 002b:00007ffd7ad94c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007f044a1e5fa0 RCX: 00007f0449f8e1ffRDX: 000000000000003e RSI: 0000200000000500 RDI: 00000000000000c8RBP: 00007ffd7ad94d20 R08: 0000000000000000 R09: 0000000000000000R10: 000000000000003e R11: 0000000000000293 R12: 0000000000000001R13: 00007f044a1e5fa0 R14: 00007f044a1e5fa0 R15: 0000000000000003 Add a NULL check immediately after __pskb_copy() to handle allocationfailures gracefully.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68972 Severity: Moderate CVSS3 score: 5.9

Description: In GnuPG through 2.4.8, if a signed message has \f at the end of a plaintext line, an adversary can construct a modified message that places additional text after the signed material, such that signature verification of the modified message succeeds (although an "invalid armor" message is printed during verification). This is related to use of \f as a marker to denote truncation of a long plaintext line.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
gpg2 > 0-0 (version in image is 2.5.5-160000.2.2).

CVE-2025-71088 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fallback earlier on simult connectionSyzkaller reports a simult-connect race leading to inconsistent fallbackstatus: WARNING: CPU: 3 PID: 33 at net/mptcp/subflow.c:1515 subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515 Modules linked in: CPU: 3 UID: 0 PID: 33 Comm: ksoftirqd/3 Not tainted syzkaller #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 RIP: 0010:subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515 Code: 89 ee e8 78 61 3c f6 40 84 ed 75 21 e8 8e 66 3c f6 44 89 fe bf 07 00 00 00 e8 c1 61 3c f6 41 83 ff 07 74 09 e8 76 66 3c f6 90 <0f> 0b 90 e8 6d 66 3c f6 48 89 df e8 e5 ad ff ff 31 ff 89 c5 89 c6 RSP: 0018:ffffc900006cf338 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888031acd100 RCX: ffffffff8b7f2abf RDX: ffff88801e6ea440 RSI: ffffffff8b7f2aca RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000004 R11: 0000000000002c10 R12: ffff88802ba69900 R13: 1ffff920000d9e67 R14: ffff888046f81800 R15: 0000000000000004 FS: 0000000000000000(0000) GS:ffff8880d69bc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000560fc0ca1670 CR3: 0000000032c3a000 CR4: 0000000000352ef0 Call Trace: tcp_data_queue+0x13b0/0x4f90 net/ipv4/tcp_input.c:5197 tcp_rcv_state_process+0xfdf/0x4ec0 net/ipv4/tcp_input.c:6922 tcp_v6_do_rcv+0x492/0x1740 net/ipv6/tcp_ipv6.c:1672 tcp_v6_rcv+0x2976/0x41e0 net/ipv6/tcp_ipv6.c:1918 ip6_protocol_deliver_rcu+0x188/0x1520 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1e4/0x4b0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ip6_input+0x105/0x2f0 net/ipv6/ip6_input.c:500 dst_input include/net/dst.h:471 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] NF_HOOK include/linux/netfilter.h:318 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x264/0x650 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core+0x12d/0x1e0 net/core/dev.c:5979 __netif_receive_skb+0x1d/0x160 net/core/dev.c:6092 process_backlog+0x442/0x15e0 net/core/dev.c:6444 __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7494 napi_poll net/core/dev.c:7557 [inline] net_rx_action+0xa9f/0xfe0 net/core/dev.c:7684 handle_softirqs+0x216/0x8e0 kernel/softirq.c:579 run_ksoftirqd kernel/softirq.c:968 [inline] run_ksoftirqd+0x3a/0x60 kernel/softirq.c:960 smpboot_thread_fn+0x3f7/0xae0 kernel/smpboot.c:160 kthread+0x3c2/0x780 kernel/kthread.c:463 ret_from_fork+0x5d7/0x6f0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 The TCP subflow can process the simult-connect syn-ack packet aftertransitioning to TCP_FIN1 state, bypassing the MPTCP fallback check,as the sk_state_change() callback is not invoked for * -> FIN_WAIT1transitions.That will move the msk socket to an inconsistent status and the nextincoming data will hit the reported splat.Close the race moving the simult-fallback check at the earliest possiblestage - that is at syn-ack generation time.About the fixes tags: [2] was supposed to also fix this issue introducedby [3]. [1] is required as a dependence: it was not explicitly marked asa fix, but it is one and it has already been backported before [3]. Inother words, this commit should be backported up to [3], including [2]and [1] if that's not already there.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38062 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookieThe 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 cookiethat must remain valid between the two steps. However, there is no lockingat the irq layer that helps protect the lifetime. Today, this works underthe assumption that the iommu domain is not changed while MSI interruptsbeing 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 bechanged while a driver is attached.Classic VFIO type1 also prevented changing the iommu domain while VFIO wasrunning as it does not support changing the "container" after starting up.However, iommufd has improved this so that the iommu domain can be changedduring VFIO operation. This potentially allows userspace to directly raceVFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) andVFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).This potentially causes both the cookie pointer and the unlocked call toiommu_get_domain_for_dev() on the MSI translation path to become UAFs.Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVAaddress 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 inpatch "iommu: Make iommu_dma_prepare_msi() into a generic operation" byusing the IOMMU group mutex.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38084 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: unshare page tables during VMA split, not beforeCurrently, __split_vma() triggers hugetlb page table unsharing throughvm_ops->may_split(). This happens before the VMA lock and rmap locks aretaken - which is too early, it allows racing VMA-locked page faults in ourprocess and racing rmap walks from other processes to cause page tables tobe 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 thatpoint, both the VMA and the rmap(s) are write-locked.An annoying detail is that we can now call into the helperhugetlb_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 lockBackporting note:This commit fixes a racy protection that was introduced in commitb30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); thatcommit claimed to fix an issue introduced in 5.13, but it should actuallyalso go all the way back.[jannh@google.com: v2]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38098 Severity: Moderate CVSS3 score: 5.8

Description: 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_sinkDon't try to operate on a drm_wb_connector as an amdgpu_dm_connector.While dereferencing aconnector->base will "work" it's wrong andmight lead to unknown bad things. Just... don't.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38101 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Fix buffer locking in ring_buffer_subbuf_order_set()Enlarge the critical section in ring_buffer_subbuf_order_set() toensure that error handling takes place with per-buffer mutex held,thus preventing list corruption and other concurrency-related issues.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38117 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Protect mgmt_pending list with its own lockThis uses a mutex to protect from concurrent access of mgmt_pendinglist which can cause crashes like:==================================================================BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPTHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call 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:600Allocated 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:600Freed 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---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38154 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Avoid using sk_socket after free when sendingThe sk->sk_socket is not locked or referenced in backlog thread, andduring the call to skb_send_sock(), there is a race condition withthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)will be affected.Race conditions:'''CPU0 CPU1backlog::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 insock_map_close() if psock is held, we simply increase the psockreference count to avoid race conditions.With this patch, if the backlog thread is running, sock_map_close() willwait for the backlog thread to complete and cancel all pending work.If no backlog running, any pending work that hasn't started by then willfail when invoked by sk_psock_get(), as the psock reference count havebeen zeroed, and sk_psock_drop() will cancel all jobs viacancel_delayed_work_sync().In summary, we require synchronization to coordinate the backlog threadand close() thread.The panic I catched:'''Workqueue: events sk_psock_backlogRIP: 0010:sock_sendmsg+0x21d/0x440RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001...Call Trace: ? 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...'''

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38415 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check return result of sb_min_blocksizeSyzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug.Syzkaller forks multiple processes which after mounting the Squashfsfilesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in theprocess of mounting a Squashfs filesystem on /dev/loop0, the failureoccurs. 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_log2is set to 64.This subsequently causes theUBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36shift 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().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38416 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: uart: Set tty->disc_data only in success pathSetting tty->disc_data before opening the NCI device means we need toclean it up on error paths. This also opens some short window if devicestarts sending data, even before NCIUARTSETDRIVER IOCTL succeeded(broken hardware?). Close the window by exposing tty->disc_data only onthe 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 beever assigned thus NULL-ified. This however should not be relevantdifference, because of "tty->disc_data=NULL" in nci_uart_tty_open().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38429 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: ep: Update read pointer only after buffer is writtenInside mhi_ep_ring_add_element, the read pointer (rd_offset) is updatedbefore the buffer is written, potentially causing race conditions wherethe host sees an updated read pointer before the buffer is actuallywritten. Updating rd_offset prematurely can lead to the host accessingan uninitialized or incomplete element, resulting in data corruption.Invoke the buffer write before updating rd_offset to ensure the elementis fully written before signaling its availability.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38464 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free in tipc_conn_close().syzbot reported a null-ptr-deref in tipc_conn_close() during netnsdismantle. [0]tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and callstipc_conn_close() for each tipc_conn.The problem is that tipc_conn_close() is called after releasing theIDR lock.At the same time, there might be tipc_conn_recv_work() running and itcould call tipc_conn_close() for the same tipc_conn and release itslast ->kref.Once we release the IDR lock in tipc_topsrv_stop(), there is noguarantee that the tipc_conn is alive.Let's hold the ref before releasing the lock and put the ref aftertipc_conn_close() in tipc_topsrv_stop().[0]:BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netCall Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00)The buggy address belongs to the page:page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0flags: 0xfff00000000100(slab)raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc>ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38552 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: plug races between subflow fail and subflow creationWe have races similar to the one addressed by the previous patch betweensubflow failing and additional subflow creation. They are just harder totrigger.The solution is similar. Use a separate flag to track the condition'socket state prevent any additional subflow creation' protected by thefallback lock.The socket fallback makes such flag true, and also receiving or sendingan MP_FAIL option.The field 'allow_infinite_fallback' is now always touched under therelevant lock, we can drop the ONCE annotation on write.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38584 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:padata: Fix pd UAF once and for allThere is a race condition/UAF in padata_reorder that goes backto the initial commit. A reference count is taken at the startof the process in padata_do_parallel, and released at the end inpadata_serial_worker.This reference count is (and only is) required for padata_replaceto function correctly. If padata_replace is never called thenthere is no issue.In the function padata_reorder which serves as the core of padata,as soon as padata is added to queue->serial.list, and the associatedspin lock released, that padata may be processed and the referencecount on pd would go away.Fix this by getting the next padata before the squeue->serial lockis released.In order to make this possible, simplify padata_reorder by onlycalling it once the next padata arrives.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38700 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocatedIn case of an ib_fast_reg_mr allocation failure during iSER setup, themachine hits a panic because iscsi_conn->dd_data is initializedunconditionally, even when no memory is allocated (dd_size == 0). Thisleads invalid pointer dereference during connection teardown.Fix by setting iscsi_conn->dd_data only if memory is actually allocated.Panic trace:------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38732 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject: don't leak dst refcount for loopback packetsrecent patches to add a WARN() when replacing skb dst entry found anold bug:WARNING: include/linux/skbuff.h:1165 skb_dst_check_unset include/linux/skbuff.h:1164 [inline]WARNING: include/linux/skbuff.h:1165 skb_dst_set include/linux/skbuff.h:1210 [inline]WARNING: include/linux/skbuff.h:1165 nf_reject_fill_skb_dst+0x2a4/0x330 net/ipv4/netfilter/nf_reject_ipv4.c:234[..]Call Trace: nf_send_unreach+0x17b/0x6e0 net/ipv4/netfilter/nf_reject_ipv4.c:325 nft_reject_inet_eval+0x4bc/0x690 net/netfilter/nft_reject_inet.c:27 expr_call_ops_eval net/netfilter/nf_tables_core.c:237 [inline] ..This is because blamed commit forgot about loopback packets.Such packets already have a dst_entry attached, even at PRE_ROUTING stage.Instead of checking hook just check if the skb already has a routeattached to it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39838 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: prevent NULL pointer dereference in UTF16 conversionThere can be a NULL pointer dereference bug here. NULL is passed to__cifs_sfu_make_node without checks, which passes it unchecked tocifs_strndup_to_utf16, which in turn passes it tocifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash.This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 andreturns NULL early to prevent dereferencing NULL pointer.Found by Linux Verification Center (linuxtesting.org) with SVACE

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39961 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd/pgtbl: Fix possible race while increase page table levelThe AMD IOMMU host page table implementation supports dynamic page table levels(up to 6 levels), starting with a 3-level configuration that expands based onIOVA address. The kernel maintains a root pointer and current page table levelto enable proper page table walks in alloc_pte()/fetch_pte() operations.The IOMMU IOVA allocator initially starts with 32-bit address and onces itsexhuasted it switches to 64-bit address (max address is determined basedon IOMMU and device DMA capability). To support larger IOVA, AMD IOMMUdriver increases page table level.But in unmap path (iommu_v1_unmap_pages()), fetch_pte() readspgtable->[root/mode] without lock. So its possible that in exteme corner case,when increase_address_space() is updating pgtable->[root/mode], fetch_pte()reads wrong page table level (pgtable->mode). It does compare the value withlevel encoded in page table and returns NULL. This will result isiommu_unmap ops to fail and upper layer may retry/log WARN_ON.CPU 0 CPU 1------ ------map pages unmap pagesalloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1)Since Page table level updates are infrequent and already synchronized with aspinlock, implement seqcount to enable lock-free read operations on the read path.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40001 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mvsas: Fix use-after-free bugs in mvs_work_queueDuring the detaching of Marvell's SAS/SATA controller, the original codecalls cancel_delayed_work() in mvs_free() to cancel the delayed workitem mwq->work_q. However, if mwq->work_q is already running, thecancel_delayed_work() may fail to cancel it. This can lead touse-after-free scenarios where mvs_free() frees the mvs_info whilemvs_work_queue() is still executing and attempts to access thealready-freed mvs_info.A typical race condition is illustrated below:CPU 0 (remove) | CPU 1 (delayed work callback)mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAFReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled and any executingdelayed work item completes before the mvs_info is deallocated.This bug was found by static analysis.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40005 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:spi: cadence-quadspi: Implement refcount to handle unbind during busydriver support indirect read and indirect write operation withassumption no force device removal(unbind) operation. Howeverforce device removal(removal) is still available to root superuser.Unbinding driver during operation causes kernel crash. This changesensure driver able to handle such operation for indirect read andindirect write by implementing refcount to track attached devicesto the controller and gracefully wait and until attached devicesremove operation completed before proceed with removal operation.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40096 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sched: Fix potential double free in drm_sched_job_add_resv_dependenciesWhen adding dependencies with drm_sched_job_add_dependency(), thatfunction consumes the fence reference both on success and failure, so inthe latter case the dma_fence_put() on the error path (xarray failed toexpand) is a double free.Interestingly this bug appears to have been present ever sincecommit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the codeback then looked like this:drm_sched_job_add_implicit_dependencies():... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; } for (; i < fence_count; i++) dma_fence_put(fences[i]);Which means for the failing 'i' the dma_fence_put was already a doublefree. Possibly there were no users at that time, or the test cases wereinsufficient to hit it.The bug was then only noticed and fixed aftercommit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2")landed, with its fixup ofcommit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies").At that point it was a slightly different flavour of a double free, whichcommit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder")noticed and attempted to fix.But it only moved the double free from happening inside thedrm_sched_job_add_dependency(), when releasing the reference not yetobtained, to the caller, when releasing the reference already released bythe former in the failure case.As such it is not easy to identify the right target for the fixes tag solets keep it simple and just continue the chain.While fixing we also improve the comment and explain the reason for takingthe reference and not dropping it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40169 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject negative offsets for ALU opsWhen verifying BPF programs, the check_alu_op() function validatesinstructions with ALU operations. The 'offset' field in theseinstructions is a signed 16-bit integer.The existing check 'insn->off > 1' was intended to ensure the offset iseither 0, or 1 for BPF_MOD/BPF_DIV. However, because 'insn->off' issigned, this check incorrectly accepts all negative values (e.g., -1).This commit tightens the validation by changing the condition to'(insn->off != 0 && insn->off != 1)'. This ensures that any valueother than the explicitly permitted 0 and 1 is rejected, hardening theverifier against malformed BPF programs.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40340 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: Fix oops in xe_gem_fault when running core_hotunplug test.I saw an oops in xe_gem_fault when running the xe-fast-feedbacktestlist against the realtime kernel without debug options enabled.The panic happens after core_hotunplug unbind-rebind finishes.Presumably what happens is that a process mmaps, unlocks becauseof the FAULT_FLAG_RETRY_NOWAIT logic, has no process memory left,causing ttm_bo_vm_dummy_page() to return VM_FAULT_NOPAGE, sincethere was nothing left to populate, and then oopses in"mem_type_is_vram(tbo->resource->mem_type)" because tbo->resourceis NULL.It's convoluted, but fits the data and explains the oops afterthe test exits.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-61780 Severity: Moderate CVSS3 score: 5.8

Description: Rack is a modular Ruby web server interface. Prior to versions 2.2.20, 3.1.18, and 3.2.3, a possible information disclosure vulnerability existed in `Rack::Sendfile` when running behind a proxy that supports `x-sendfile` headers (such as Nginx). Specially crafted headers could cause `Rack::Sendfile` to miscommunicate with the proxy and trigger unintended internal requests, potentially bypassing proxy-level access restrictions. When `Rack::Sendfile` received untrusted `x-sendfile-type` or `x-accel-mapping` headers from a client, it would interpret them as proxy configuration directives. This could cause the middleware to send a "redirect" response to the proxy, prompting it to reissue a new internal request that was not subject to the proxy's access controls. An attacker could exploit this by setting a crafted `x-sendfile-type: x-accel-redirect` header, setting a crafted `x-accel-mapping` header, and requesting a path that qualifies for proxy-based acceleration. Attackers could bypass proxy-enforced restrictions and access internal endpoints intended to be protected (such as administrative pages). The vulnerability did not allow arbitrary file reads but could expose sensitive application routes. This issue only affected systems meeting all of the following conditions: The application used `Rack::Sendfile` with a proxy that supports `x-accel-redirect` (e.g., Nginx); the proxy did **not** always set or remove the `x-sendfile-type` and `x-accel-mapping` headers; and the application exposed an endpoint that returned a body responding to `.to_path`. Users should upgrade to Rack versions 2.2.20, 3.1.18, or 3.2.3, which require explicit configuration to enable `x-accel-redirect`. Alternatively, configure the proxy to always set or strip the header, or in Rails applications, disable sendfile completely.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
hawk2 > 0-0 (version in image is 2.7.0+git.1742310530.bfcd0e2c-160000.2.2).

CVE-2025-68263 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: ipc: fix use-after-free in ipc_msg_send_requestipc_msg_send_request() waits for a generic netlink reply using anipc_msg_table_entry on the stack. The generic netlink handler(handle_generic_event()/handle_response()) fills entry->response underipc_msg_table_lock, but ipc_msg_send_request() used to validate and freeentry->response without holding the same lock.Under high concurrency this allows a race where handle_response() iscopying data into entry->response while ipc_msg_send_request() has justfreed it, leading to a slab-use-after-free reported by KASAN inhandle_generic_event(): BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd] Write of size 12 at addr ffff888198ee6e20 by task pool/109349 ... Freed by task: kvfree ipc_msg_send_request [ksmbd] ksmbd_rpc_open -> ksmbd_session_rpc_open [ksmbd]Fix by:- Taking ipc_msg_table_lock in ipc_msg_send_request() while validating entry->response, freeing it when invalid, and removing the entry from ipc_msg_table.- Returning the final entry->response pointer to the caller only after the hash entry is removed under the lock.- Returning NULL in the error path, preserving the original API semantics.This makes all accesses to entry->response consistent withhandle_response(), which already updates and fills the response bufferunder ipc_msg_table_lock, and closes the race that allowed the UAF.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68265 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:nvme: fix admin request_queue lifetimeThe namespaces can access the controller's admin request_queue, andstale references on the namespaces may exist after tearing down thecontroller. Ensure the admin request_queue is active by moving thecontroller's 'put' to after all controller references have been releasedto ensure no one is can access the request_queue. This fixes a reporteduse-after-free bug: BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0 Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287 CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G E 6.13.2-ga1582f1a031e #15 Tainted: [E]=UNSIGNED_MODULE Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025 Call Trace: dump_stack_lvl+0x4f/0x60 print_report+0xc4/0x620 ? _raw_spin_lock_irqsave+0x70/0xb0 ? _raw_read_unlock_irqrestore+0x30/0x30 ? blk_queue_enter+0x41c/0x4a0 kasan_report+0xab/0xe0 ? blk_queue_enter+0x41c/0x4a0 blk_queue_enter+0x41c/0x4a0 ? __irq_work_queue_local+0x75/0x1d0 ? blk_queue_start_drain+0x70/0x70 ? irq_work_queue+0x18/0x20 ? vprintk_emit.part.0+0x1cc/0x350 ? wake_up_klogd_work_func+0x60/0x60 blk_mq_alloc_request+0x2b7/0x6b0 ? __blk_mq_alloc_requests+0x1060/0x1060 ? __switch_to+0x5b7/0x1060 nvme_submit_user_cmd+0xa9/0x330 nvme_user_cmd.isra.0+0x240/0x3f0 ? force_sigsegv+0xe0/0xe0 ? nvme_user_cmd64+0x400/0x400 ? vfs_fileattr_set+0x9b0/0x9b0 ? cgroup_update_frozen_flag+0x24/0x1c0 ? cgroup_leave_frozen+0x204/0x330 ? nvme_ioctl+0x7c/0x2c0 blkdev_ioctl+0x1a8/0x4d0 ? blkdev_common_ioctl+0x1930/0x1930 ? fdget+0x54/0x380 __x64_sys_ioctl+0x129/0x190 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f765f703b0b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000 R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003 R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68310 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdumpDo not block PCI config accesses through pci_cfg_access_lock() whenexecuting the s390 variant of PCI error recovery: Acquire justdevice_lock() instead of pci_dev_lock() as powerpc's EEH andgenerig PCI AER processing do.During error recovery testing a pair of tasks was reported to be hung:mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not workingINFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]No kernel log of the exact same error with an upstream kernel isavailable - but the very same deadlock situation can be constructed there,too:- task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock()- task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock.A similar deadlock situation can be reproduced by requesting acrdump with > devlink health dump show pci/ reporter fw_fatalwhile PCI error recovery is executed on the same physical functionby mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw Tests with this patch failed to reproduce that second deadlock situation,the devlink command is rejected with "kernel answers: Permission denied" -and we get a kernel log message of:mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5because the config read of VSC_SEMAPHORE is rejected by the underlyinghardware.Two prior attempts to address this issue have been discussed andultimately rejected [see link], with the primary argument that s390'simplementation of PCI error recovery is imposing restrictions thatneither powerpc's EEH nor PCI AER handling need. Tests show that PCIerror recovery on s390 is running to completion even without blockingaccess to PCI config space.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68795 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: Avoid overflowing userspace buffer on stats queryThe ethtool -S command operates across three ioctl calls:ETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, andETHTOOL_GSTATS for the values.If the number of stats changes between these calls (e.g., due to devicereconfiguration), userspace's buffer allocation will be incorrect,potentially leading to buffer overflow.Drivers are generally expected to maintain stable stat counts, but somedrivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, makingthis scenario possible.Some drivers try to handle this internally:- bnad_get_ethtool_stats() returns early in case stats.n_stats is not equal to the driver's stats count.- micrel/ksz884x also makes sure not to write anything beyond stats.n_stats and overflow the buffer.However, both use stats.n_stats which is already assigned with the valuereturned from get_sset_count(), hence won't solve the issue describedhere.Change ethtool_get_strings(), ethtool_get_stats(),ethtool_get_phy_stats() to not return anything in case of a mismatchbetween userspace's size and get_sset_size(), to prevent bufferoverflow.The returned n_stats value will be equal to zero, to reflect thatnothing has been returned.This could result in one of two cases when using upstream ethtool,depending on when the size change is detected:1. When detected in ethtool_get_strings(): # ethtool -S eth2 no stats available2. When detected in get stats, all stats will be reported as zero.Both cases are presumably transient, and a subsequent ethtool callshould succeed.Other than the overflow avoidance, these two cases are very evident (nooutput/cleared stats), which is arguably better than presentingincorrect/shifted stats.I also considered returning an error instead of a "silent" response, butthat seems more destructive towards userspace apps.Notes:- This patch does not claim to fix the inherent race, it only makes sure that we do not overflow the userspace buffer, and makes for a more predictable behavior.- RTNL lock is held during each ioctl, the race window exists between the separate ioctl calls when the lock is released.- Userspace ethtool always fills stats.n_stats, but it is likely that these stats ioctls are implemented in other userspace applications which might not fill it. The added code checks that it's not zero, to prevent any regressions.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39848 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: properly unshare skbs in ax25_kiss_rcv()Bernard Pidoux reported a regression apparently caused by commitc353e8983e0d ("net: introduce per netns packet chains").skb->dev becomes NULL and we crash in __netif_receive_skb_core().Before above commit, different kind of bugs or corruptions could happenwithout a major crash.But the root cause is that ax25_kiss_rcv() can queue/mangle input skbwithout checking if this skb is shared or not.Many thanks to Bernard Pidoux for his help, diagnosis and tests.We had a similar issue years ago fixed with commit 7aaed57c5c28("phonet: properly unshare skbs in phonet_rcv()").

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68736 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:landlock: Fix handling of disconnected directoriesDisconnected files or directories can appear when they are visible andopened from a bind mount, but have been renamed or moved from the sourceof the bind mount in a way that makes them inaccessible from the mountpoint (i.e. out of scope).Previously, access rights tied to files or directories opened through adisconnected directory were collected by walking the related hierarchydown to the root of the filesystem, without taking into account themount point because it couldn't be found. This could lead toinconsistent access results, potential access right widening, andhard-to-debug renames, especially since such paths cannot be printed.For a sandboxed task to create a disconnected directory, it needs tohave write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) tothe underlying source of the bind mount, and read access to the relatedmount point. Because a sandboxed task cannot acquire more accessrights than those defined by its Landlock domain, this could lead toinconsistent access rights due to missing permissions that should beinherited from the mount point hierarchy, while inheriting permissionsfrom the filesystem hierarchy hidden by this mount point instead.Landlock now handles files and directories opened from disconnecteddirectories by taking into account the filesystem hierarchy when themount point is not found in the hierarchy walk, and also always takinginto account the mount point from which these disconnected directorieswere opened. This ensures that a rename is not allowed if it wouldwiden access rights [1].The rationale is that, even if disconnected hierarchies might not bevisible or accessible to a sandboxed task, relying on the collectedaccess rights from them improves the guarantee that access rights willnot be widened during a rename because of the access right comparisonbetween the source and the destination (see LANDLOCK_ACCESS_FS_REFER).It may look like this would grant more access on disconnected files anddirectories, but the security policies are always enforced for all theevaluated hierarchies. This new behavior should be less surprising tousers and safer from an access control perspective.Remove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() andfix the related comment.Because opened files have their access rights stored in the related filesecurity properties, there is no impact for disconnected or unlinkedfiles.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2024-44974 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: avoid possible UaF when selecting endpselect_local_address() and select_signal_address() both select anendpoint entry from the list inside an RCU protected section, but returna reference to it, to be read later on. If the entry is dereferencedafter the RCU unlock, reading info could cause a Use-after-Free.A simple solution is to copy the required info while inside the RCUprotected section to avoid any risk of UaF later. The address ID mightneed to be modified later to handle the ID0 case later, so a copy seemsOK to deal with.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-55158 Severity: Moderate CVSS3 score: 5.6

Description: Vim is an open source, command line text editor. In versions from 9.1.1231 to before 9.1.1406, when processing nested tuples during Vim9 script import operations, an error during evaluation can trigger a double-free in Vim's internal typed value (typval_T) management. Specifically, the clear_tv() function may attempt to free memory that has already been deallocated, due to improper lifetime handling in the handle_import / ex_import code paths. The vulnerability can only be triggered if a user explicitly opens and executes a specially crafted Vim script. This issue has been patched in version 9.1.1406.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
vim > 0-0 (version in image is 9.1.1406-160000.3.2).

CVE-2025-71087 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:iavf: fix off-by-one issues in iavf_config_rss_reg()There are off-by-one bugs when configuring RSS hash key and lookuptable, causing out-of-bounds reads to memory [1] and out-of-boundswrites to device registers.Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"),the loop upper bounds were: i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEXwhich is safe since the value is the last valid index.That commit changed the bounds to: i <= adapter->rss_{key,lut}_size / 4where `rss_{key,lut}_size / 4` is the number of dwords, so the lastvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `<=`accesses one element past the end.Fix the issues by using `<` instead of `<=`, ensuring we do not exceedthe bounds.[1] KASAN splat about rss_key_size off-by-one BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63 CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavf_watchdog_task Call Trace: dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf_watchdog_task+0x2be7/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 Allocated by task 63: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2022-50253 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: make sure skb->len != 0 when redirecting to a tunneling devicesyzkaller managed to trigger another case where skb->len == 0when we enter __dev_queue_xmit:WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline]WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295Call Trace: dev_queue_xmit+0x17/0x20 net/core/dev.c:4406 __bpf_tx_skb net/core/filter.c:2115 [inline] __bpf_redirect_no_mac net/core/filter.c:2140 [inline] __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163 ____bpf_clone_redirect net/core/filter.c:2447 [inline] bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419 bpf_prog_48159a89cb4a9a16+0x59/0x5e bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline] __bpf_prog_run include/linux/filter.h:596 [inline] bpf_prog_run include/linux/filter.h:603 [inline] bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402 bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170 bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648 __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005 __do_sys_bpf kernel/bpf/syscall.c:5091 [inline] __se_sys_bpf kernel/bpf/syscall.c:5089 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089 do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x61/0xc6The reproducer doesn't really reproduce outside of syzkallerenvironment, so I'm taking a guess here. It looks like wedo generate correct ETH_HLEN-sized packet, but we redirectthe packet to the tunneling device. Before we do so, we__skb_pull l2 header and arrive again at skb->len == 0.Doesn't seem like we can do anything better than havingan explicit check after __skb_pull?

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2023-52920 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: support non-r10 register spill/fill to/from stack in precision trackingUse instruction (jump) history to record instructions that performedregister spill/fill to/from stack, regardless if this was done throughread-only r10 register, or any other register after copying r10 into it*and* potentially adjusting offset.To make this work reliably, we push extra per-instruction flags intoinstruction history, encoding stack slot index (spi) and stack framenumber in extra 10 bit flags we take away from prev_idx in instructionhistory. We don't touch idx field for maximum performance, as it'schecked most frequently during backtracking.This change removes basically the last remaining practical limitation ofprecision backtracking logic in BPF verifier. It fixes knowndeficiencies, but also opens up new opportunities to reduce number ofverified states, explored in the subsequent patches.There are only three differences in selftests' BPF object filesaccording to veristat, all in the positive direction (less states).File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)-------------------------------------- ------------- --------- --------- ------------- ---------- ---------- -------------test_cls_redirect_dynptr.bpf.linked3.o cls_redirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%)xdp_synproxy_kern.bpf.linked3.o syncookie_tc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%)xdp_synproxy_kern.bpf.linked3.o syncookie_xdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%)Note, I avoided renaming jmp_history to more generic insn_hist tominimize number of lines changed and potential merge conflicts betweenbpf and bpf-next trees.Notice also cur_hist_entry pointer reset to NULL at the beginning ofinstruction verification loop. This pointer avoids the problem ofrelying on last jump history entry's insn_idx to determine whether wealready have entry for current instruction or not. It can happen that weadded jump history entry because current instruction is_jmp_point(), butalso we need to add instruction flags for stack access. In this case, wedon't want to entries, so we need to reuse last added entry, if it ispresent.Relying on insn_idx comparison has the same ambiguity problem as the onethat was fixed recently in [0], so we avoid that. [0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2023-53431 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Handle enclosure with just a primary component gracefullyThis reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosurehas no components") and introduces proper handling of case where there areno detected secondary components, but primary component (enumerated innum_enclosures) does exist. That fix was originally proposed by Ding Hui.Completely ignoring devices that have one primary enclosure and nosecondary one results in ses_intf_add() bailing completely scsi 2:0:0:254: enclosure has no enumerated components scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations sucheven on valid configurations with 1 primary and 0 secondary enclosures asbelow: # sg_ses /dev/sg0 3PARdata SES 3321 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Short Enclosure Status (SES) [ses] [0x8] # sg_ses -p cf /dev/sg0 3PARdata SES 3321 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor list Subenclosure identifier: 0 [primary] relative ES process id: 0, number of ES processes: 1 number of type descriptor headers: 1 enclosure logical identifier (hex): 20000002ac02068d enclosure vendor: 3PARdata product: VV rev: 3321 type descriptor header and text list Element type: Unspecified, subenclosure id: 0 number of possible elements: 1The changelog for the original fix follows=====We can get a crash when disconnecting the iSCSI session,the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,but not saved in edev->component[i].scratchIn this situation, edev->component[0].scratch is an invalid pointer,when kfree it in ses_intf_remove_enclosure, a crash like above would happenThe call trace also could be other random cases when kfree cannot catchthe invalid pointerWe should not use edev->component[] array when the components count is 0We also need check index when use edev->component[] array inses_enclosure_data_process=====

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2023-53992 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: ocb: don't leave if not joinedIf there's no OCB state, don't ask the driver/mac80211 toleave, since that's just confusing. Since set/clear thechandef state, that's a simple check.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2023-54088 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: hold queue_lock when removing blkg->q_nodeWhen blkg is removed from q->blkg_list from blkg_free_workfn(), queue_lockhas to be held, otherwise, all kinds of bugs(list corruption, hard lockup,..) can be triggered from blkg_destroy_all().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-35839 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: replace physindev with physinif in nf_bridge_infoAn skb can be added to a neigh->arp_queue while waiting for an arpreply. Where original skb's skb->dev can be different to neigh'sneigh->dev. For instance in case of bridging dnated skb from one veth toanother, the skb would be added to a neigh->arp_queue of the bridge.As skb->dev can be reset back to nf_bridge->physindev and used, and asthere is no explicit mechanism that prevents this physindev from beenfreed under us (for instance neigh_flush_dev doesn't cleanup skbs fromdifferent device's neigh queue) we can crash on e.g. this stack:arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finishLet's use plain ifindex instead of net_device link. To peek into theoriginal net_device we will use dev_get_by_index_rcu(). Thus either weget device and are safe to use it or we don't get it and drop skb.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-36000 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix missing hugetlb_lock for resv unchargeThere is a recent report on UFFDIO_COPY over hugetlb:https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/350: lockdep_assert_held(&hugetlb_lock);Should be an issue in hugetlb but triggered in an userfault context, whereit goes into the unlikely path where two threads modifying the resv maptogether. Mike has a fix in that path for resv uncharge but it looks likethe locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()will update the cgroup pointer, so it requires to be called with the lockheld.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-38589 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netrom: fix possible dead-lock in nr_rt_ioctl()syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)[1]WARNING: possible circular locking dependency detected6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted------------------------------------------------------syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697but task is already holding lock: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_remove_node net/netrom/nr_route.c:299 [inline] nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f-> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fother info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nr_node_list_lock); lock(&nr_node->node_lock); lock(nr_node_list_lock); lock(&nr_node->node_lock); *** DEADLOCK ***1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f70---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-44996 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: fix recursive ->recvmsg callsAfter a vsock socket has been added to a BPF sockmap, its prot->recvmsghas been replaced with vsock_bpf_recvmsg(). Thus the followingrecursiion could happen:vsock_bpf_recvmsg() -> __vsock_recvmsg() -> vsock_connectible_recvmsg() -> prot->recvmsg() -> vsock_bpf_recvmsg() againWe need to fix it by calling the original ->recvmsg() without any BPFsockmap logic in __vsock_recvmsg().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-46733 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix qgroup reserve leaks in cow_file_rangeIn the buffered write path, the dirty page owns the qgroup reserve untilit creates an ordered_extent.Therefore, any errors that occur before the ordered_extent is createdmust free that reservation, or else the space is leaked. The fstestgeneric/475 exercises various IO error paths, and is able to triggererrors in cow_file_range where we fail to get to allocating the orderedextent. Note that because we *do* clear delalloc, we are likely toremove the inode from the delalloc list, so the inodes/pages to not haveinvalidate/launder called on them in the commit abort path.This results in failures at the unmount stage of the test that look like: BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs] Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:close_ctree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Call Trace: ? close_ctree+0x222/0x4d0 [btrfs] ? __warn.cold+0x8e/0xea ? close_ctree+0x222/0x4d0 [btrfs] ? report_bug+0xff/0x140 ? handle_bug+0x3b/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? close_ctree+0x222/0x4d0 [btrfs] generic_shutdown_super+0x70/0x160 kill_anon_super+0x11/0x40 btrfs_kill_super+0x11/0x20 [btrfs] deactivate_locked_super+0x2e/0xa0 cleanup_mnt+0xb5/0x150 task_work_run+0x57/0x80 syscall_exit_to_user_mode+0x121/0x130 do_syscall_64+0xab/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f916847a887 ---[ end trace 0000000000000000 ]--- BTRFS error (device dm-8 state EA): qgroup reserved space leakedCases 2 and 3 in the out_reserve path both pertain to this type of leakand must free the reserved qgroup data. Because it is already an errorpath, I opted not to handle the possible errors inbtrfs_free_qgroup_data.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-46763 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fou: Fix null-ptr-deref in GRO.We observed a null-ptr-deref in fou_gro_receive() while shutting downa host. [0]The NULL pointer is sk->sk_user_data, and the offset 8 is of protocolin struct fou.When fou_release() is called due to netns dismantle or explicit tunnelteardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.Then, the tunnel socket is destroyed after a single RCU grace period.So, in-flight udp4_gro_receive() could find the socket and execute theFOU GRO handler, where sk->sk_user_data could be NULL.Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULLchecks in FOU GRO handlers.[0]:BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0SMP PTICPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809) do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900RDX: ffff93daee800000 RSI: ffff93d---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-50106 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix race between laundromat and free_stateidThere is a race between laundromat handling of revoked delegationsand a client sending free_stateid operation. Laundromat threadfinds that delegation has expired and needs to be revoked so itmarks the delegation stid revoked and it puts it on a reaper listbut then it unlock the state lock and the actual delegation revocationhappens without the lock. Once the stid is marked revoked a racingfree_stateid processing thread does the following (1) it callslist_del_init() which removes it from the reaper list and (2) freesthe delegation stid structure. The laundromat thread ends up notcalling the revoke_delegation() function for this particular delegationbut that means it will no release the lock lease that exists onthe file.Now, a new open for this file comes in and ends up finding thatlease list isn't empty and calls nfsd_breaker_owns_lease() which endsup trying to derefence a freed delegation stateid. Leading to thefollowint use-after-free KASAN warning:kernel: ==================================================================kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205kernel:kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024kernel: Call trace:kernel: dump_backtrace+0x98/0x120kernel: show_stack+0x1c/0x30kernel: dump_stack_lvl+0x80/0xe8kernel: print_address_description.constprop.0+0x84/0x390kernel: print_report+0xa4/0x268kernel: kasan_report+0xb4/0xf8kernel: __asan_report_load8_noabort+0x1c/0x28kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd]kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd]kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd]kernel: nfsd4_open+0xa08/0xe80 [nfsd]kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd]kernel: nfsd_dispatch+0x22c/0x718 [nfsd]kernel: svc_process_common+0x8e8/0x1960 [sunrpc]kernel: svc_process+0x3d4/0x7e0 [sunrpc]kernel: svc_handle_xprt+0x828/0xe10 [sunrpc]kernel: svc_recv+0x2cc/0x6a8 [sunrpc]kernel: nfsd+0x270/0x400 [nfsd]kernel: kthread+0x288/0x310kernel: ret_from_fork+0x10/0x20This patch proposes a fixed that's based on adding 2 new additionalstid's sc_status values that help coordinate between the laundromatand other operations (nfsd4_free_stateid() and nfsd4_delegreturn()).First to make sure, that once the stid is marked revoked, it is notremoved by the nfsd4_free_stateid(), the laundromat take a referenceon the stateid. Then, coordinating whether the stid has been puton the cl_revoked list or we are processing FREE_STATEID and need tomake sure to remove it from the list, each check that state and actaccordingly. If laundromat has added to the cl_revoke list beforethe arrival of FREE_STATEID, then nfsd4_free_stateid() knows to removeit from the list. If nfsd4_free_stateid() finds that operations arrivedbefore laundromat has placed it on cl_revoke list, it marks the statefreed and then laundromat will no longer add it to the list.Also, for nfsd4_delegreturn() when looking for the specified stid,we need to access stid that are marked removed or freeable, it meansthe laundromat has started processing it but hasn't finished and thisdelegreturn needs to return nfserr_deleg_revoked and notnfserr_bad_stateid. The latter will not trigger a FREE_STATEID and thelack of it will leave this stid on the cl_revoked list indefinitely.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-50223 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/numa: Fix the potential null pointer dereference in task_numa_work()When running stress-ng-vm-segv test, we found a null pointer dereferenceerror in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel...stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV errorhandling function of the system, which tries to cause a SIGSEGV error onreturn from unmapping the whole address space of the child process.Normally this program will not cause kernel crashes. But before themunmap system call returns to user mode, a potential task_numa_work()for numa balancing could be added and executed. In this scenario, since thechild process has no vma after munmap, the vma_next() in task_numa_work()will return a null pointer even if the vma iterator restarts from 0.Recheck the vma pointer before dereferencing it in task_numa_work().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-53093 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-multipath: defer partition scanningWe need to suppress the partition scan from occuring within thecontroller's scan_work context. If a path error occurs here, the IO willwait until a path becomes available or all paths are torn down, but thataction also occurs within scan_work, so it would deadlock. Defer thepartion scan to a different context that does not block scan_work.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-53124 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix data-races around sk->sk_forward_allocSyzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]---Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked,which triggers a data-race around sk->sk_forward_alloc:tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add()In this syzkaller testcase, two threads calltcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes likethis: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() whensk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().Fix the same issue in dccp_v6_do_rcv().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-53134 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: imx93-blk-ctrl: correct remove pathThe check condition should be 'i < bc->onecell_data.num_domains', not'bc->onecell_data.num_domains' which will make the look never finishand cause kernel panic.Also disable runtime to address"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!"

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-53135 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKENHide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable supportfor virtualizing Intel PT via guest/host mode unless BROKEN=y. There aremyriad bugs in the implementation, some of which are fatal to the guest,and others which put the stability and health of the host at risk.For guest fatalities, the most glaring issue is that KVM fails to ensuretracing is disabled, and *stays* disabled prior to VM-Enter, which isnecessary as hardware disallows loading (the guest's) RTIT_CTL if tracingis enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the "load IA32_RTIT_CTL" VM-entry control must be 0.On the host side, KVM doesn't validate the guest CPUID configurationprovided by userspace, and even worse, uses the guest configuration todecide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuringguest CPUID to enumerate more address ranges than are supported in hardwarewill result in KVM trying to passthrough, save, and load non-existent MSRs,which generates a variety of WARNs, ToPA ERRORs in the host, a potentialdeadlock, etc.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-53139 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: fix possible UAF in sctp_v6_available()A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hintsthat sctp_v6_available() is calling dev_get_by_index_rcu()and ipv6_chk_addr() without holding rcu.[1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctpstack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48All code======== 0: 44 00 00 add %r8b,(%rax) 3: 48 8b 15 39 8c 0c 00 mov 0xc8c39(%rip),%rdx # 0xc8c43 a: f7 d8 neg %eax c: 64 89 02 mov %eax,%fs:(%rdx) f: b8 ff ff ff ff mov $0xffffffff,%eax 14: eb bd jmp 0xffffffffffffffd3 16: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) 1d: 00 00 00 20: 0f 1f 00 nopl (%rax) 23: b8 31 00 00 00 mov $0x31,%eax 28: 0f 05 syscall 2a:* 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax <-- trapping instruction 30: 73 01 jae 0x33 32: c3 ret 33: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c43 3a: f7 d8 neg %eax 3c: 64 89 01 mov %eax,%fs:(%rcx) 3f: 48 rex.WCode starting with the faulting instruction=========================================== 0: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax 6: 73 01 jae 0x9 8: c3 ret 9: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c19 10: f7 d8 neg %eax 12: 64 89 01 mov %eax,%fs:(%rcx) 15: 48 rex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-57891 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched_ext: Fix invalid irq restore in scx_ops_bypass()While adding outer irqsave/restore locking, 0e7ffff1b811 ("scx: Fix racinessin scx_ops_bypass()") forgot to convert an inner rq_unlock_irqrestore() torq_unlock() which could re-enable IRQ prematurely leading to the followingwarning: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 1 PID: 96 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Sched_ext: create_dsq (enabling) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : warn_bogus_irq_restore+0x30/0x40 lr : warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 (P) warn_bogus_irq_restore+0x30/0x40 (L) scx_ops_bypass+0x224/0x3b8 scx_ops_enable.isra.0+0x2c8/0xaa8 bpf_scx_reg+0x18/0x30 ... irq event stamp: 33739 hardirqs last enabled at (33739): [] scx_ops_bypass+0x174/0x3b8 hardirqs last disabled at (33738): [] _raw_spin_lock_irqsave+0xb4/0xd8Drop the stray _irqrestore().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2024-57951 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hrtimers: Handle CPU state correctly on hotplugConsider a scenario where a CPU transitions from CPUHP_ONLINE to halfwaythrough a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back toCPUHP_ONLINE:Since hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains setto 1 throughout. However, during a CPU unplug operation, the tick and theclockevents are shut down at CPUHP_AP_TICK_DYING. On return to the onlinestate, for instance CFS incorrectly assumes that the hrtick is alreadyactive, and the chance of the clockevent device to transition to oneshotmode is also lost forever for the CPU, unless it goes back to a lower statethan CPUHP_HRTIMERS_PREPARE once.This round-trip reveals another issue; cpu_base.online is not set to 1after the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().Aside of that, the bulk of the per CPU state is not reset either, whichmeans there are dangling pointers in the worst case.Address this by adding a corresponding startup() callback, which resets thestale per CPU state and sets the online flag.[ tglx: Make the new callback unconditionally available, remove the online modification in the prepare() callback and clear the remaining state in the starting callback instead of the prepare callback ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2024-57952 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Revert "libfs: fix infinite directory reads for offset dir"The current directory offset allocator (based on mtree_alloc_cyclic)stores the next offset value to return in octx->next_offset. Thismechanism typically returns values that increase monotonically overtime. Eventually, though, the newly allocated offset value wrapsback to a low number (say, 2) which is smaller than other already-allocated offset values.Yu Kuai reports that, after commit 64a7ce76fb90("libfs: fix infinite directory reads for offset dir"), if adirectory's offset allocator wraps, existing entries are no longervisible via readdir/getdents because offset_readdir() stops listingentries once an entry's offset is larger than octx->next_offset.These entries vanish persistently -- they can be looked up, but willnever again appear in readdir(3) output.The reason for this is that the commit treats directory offsets asmonotonically increasing integer values rather than opaque cookies,and introduces this comparison: if (dentry2offset(dentry) >= last_index) {On 64-bit platforms, the directory offset value upper bound is2^63 - 1. Directory offsets will monotonically increase for millionsof years without wrapping.On 32-bit platforms, however, LONG_MAX is 2^31 - 1. The allocatorcan wrap after only a few weeks (at worst).Revert commit 64a7ce76fb90 ("libfs: fix infinite directory reads foroffset dir") to prepare for a fix that can work properly on 32-bitsystems and might apply to recent LTS kernels where shmem employsthe simple_offset mechanism.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2024-58090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/core: Prevent rescheduling when interrupts are disabledDavid reported a warning observed while loop testing kexec jump: Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180The corresponding interrupt flag trace: hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90That means __up_console_sem() was invoked with interrupts enabled. Furtherinstrumentation revealed that in the interrupt disabled section of kexecjump one of the syscore_suspend() callbacks woke up a task, which set theNEED_RESCHED flag. A later callback in the resume path invokedcond_resched() which in turn led to the invocation of the scheduler: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180This is a long standing problem, which probably got more visible withthe recent printk changes. Something does a task wakeup and thescheduler sets the NEED_RESCHED flag. cond_resched() sees it set andinvokes schedule() from a completely bogus context. The schedulerenables interrupts after context switching, which causes the abovewarning at the end.Quite some of the code paths in syscore_suspend()/resume() can result intriggering a wakeup with the exactly same consequences. They might nothave done so yet, but as they share a lot of code with normal operationsit's just a question of time.The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY schedulingmodels. Full preemption is not affected as cond_resched() is disabled andthe preemption check preemptible() takes the interrupt disabled flag intoaccount.Cure the problem by adding a corresponding check into cond_resched().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-10911 Severity: Moderate CVSS3 score: 5.5

Description: A use-after-free vulnerability was found in libxslt while parsing xsl nodes that may lead to the dereference of expired pointers and application crash.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libexslt0 < 1.1.43-160000.3.1 (version in image is 1.1.43-160000.2.2).

CVE-2025-12748 Severity: Moderate CVSS3 score: 5.5

Description: A flaw was discovered in libvirt in the XML file processing. More specifically, the parsing of user provided XML files was performed before the ACL checks. A malicious user with limited permissions could exploit this flaw by submitting a specially crafted XML file, causing libvirt to allocate too much memory on the host. The excessive memory consumption could lead to a libvirt process crash on the host, resulting in a denial-of-service condition.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libvirt-client < 11.4.0-160000.3.1 (version in image is 11.4.0-160000.2.2).

CVE-2025-13193 Severity: Moderate CVSS3 score: 5.5

Description: A flaw was found in libvirt. External inactive snapshots for shut-down VMs are incorrectly created as world-readable, making it possible for unprivileged users to inspect the guest OS contents. This results in an information disclosure vulnerability.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libvirt-client < 11.4.0-160000.3.1 (version in image is 11.4.0-160000.2.2).

CVE-2025-15281 Severity: Moderate CVSS3 score: 5.5

Description: Calling wordexp with WRDE_REUSE in conjunction with WRDE_APPEND in the GNU C Library version 2.0 to version 2.42 may cause the interface to return uninitialized memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
glibc < 2.40-160000.3.1 (version in image is 2.40-160000.2.2).

CVE-2025-21736 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix possible int overflows in nilfs_fiemap()Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its resultby being prepared to go through potentially maxblocks == INT_MAX blocks,the value in n may experience an overflow caused by left shift of blkbits.While it is extremely unlikely to occur, play it safe and cast right handexpression to wider type to mitigate the issue.Found by Linux Verification Center (linuxtesting.org) with static analysistool SVACE.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-21816 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYINGhrtimers are migrated away from the dying CPU to any online target atthe CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timershandling tasks involved in the CPU hotplug forward progress.However wakeups can still be performed by the outgoing CPU afterCPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers beingarmed. Depending on several considerations (crystal ball power managementbased election, earliest timer already enqueued, timer migration enabled ornot), the target may eventually be the current CPU even if offline. If thathappens, the timer is eventually ignored.The most notable example is RCU which had to deal with each and every ofthose wake-ups by deferring them to an online CPU, along with relatedworkarounds:_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)_ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)_ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)The problem isn't confined to RCU though as the stop machine kthread(which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the endof its work through cpu_stop_signal_done() and performs a wake up thateventually arms the deadline server timer: WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted Stopper: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0 RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0 Call Trace: start_dl_timer enqueue_dl_entity dl_server_start enqueue_task_fair enqueue_task ttwu_do_activate try_to_wake_up complete cpu_stopper_threadInstead of providing yet another bandaid to work around the situation, fixit in the hrtimers infrastructure instead: always migrate away a timer toan online target whenever it is enqueued from an offline CPU.This will also allow to revert all the above RCU disgraceful hacks.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-22026 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: don't ignore the return code of svc_proc_register()Currently, nfsd_proc_stat_init() ignores the return value ofsvc_proc_register(). If the procfile creation fails, then the kernelwill WARN when it tries to remove the entry later.Fix nfsd_proc_stat_init() to return the same type of pointer assvc_proc_register(), and fix up nfsd_net_init() to check that and failthe nfsd_net construction if it occurs.svc_proc_register() can fail if the dentry can't be allocated, or if anidentical dentry already exists. The second case is pretty unlikely inthe nfsd_net construction codepath, so if this happens, return -ENOMEM.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-22034 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/gup: reject FOLL_SPLIT_PMD with hugetlb VMAsPatch series "mm: fixes for device-exclusive entries (hmm)", v2.Discussing the PageTail() call in make_device_exclusive_range() withWilly, I recently discovered [1] that device-exclusive handling does notproperly work with THP, making the hmm-tests selftests fail if THPs areenabled on the system.Looking into more details, I found that hugetlb is not properly fenced,and I realized that something that was bugging me for longer -- howdevice-exclusive entries interact with mapcounts -- completely breaksmigration/swapout/split/hwpoison handling of these folios while they havedevice-exclusive PTEs.The program below can be used to allocate 1 GiB worth of pages and makingthem device-exclusive on a kernel with CONFIG_TEST_HMM.Once they are device-exclusive, these folios cannot get swapped out(proc$pid/smaps_rollup will always indicate 1 GiB RSS no matter how muchone forces memory reclaim), and when having a memory block onlined toZONE_MOVABLE, trying to offline it will loop forever and complain aboutfailed migration of a page that should be movable.# echo offline > /sys/devices/system/memory/memory136/state# echo online_movable > /sys/devices/system/memory/memory136/state# ./hmm-swap &... wait until everything is device-exclusive# echo offline > /sys/devices/system/memory/memory136/state[ 285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x7f20671f7 pfn:0x442b6a[ 285.196618][T14882] memcg:ffff888179298000[ 285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate| dirty|active|owner_2|swapbacked|node=1|zone=3|lastcpupid=0x7ff)[ 285.201734][T14882] raw: ...[ 285.204464][T14882] raw: ...[ 285.207196][T14882] page dumped because: migration failure[ 285.209072][T14882] page_owner tracks the page as allocated[ 285.210915][T14882] page last allocated via order 0, migratetype Movable, gfp_mask 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), id 14926, tgid 14926 (hmm-swap), ts 254506295376, free_ts 227402023774[ 285.216765][T14882] post_alloc_hook+0x197/0x1b0[ 285.218874][T14882] get_page_from_freelist+0x76e/0x3280[ 285.220864][T14882] __alloc_frozen_pages_noprof+0x38e/0x2740[ 285.223302][T14882] alloc_pages_mpol+0x1fc/0x540[ 285.225130][T14882] folio_alloc_mpol_noprof+0x36/0x340[ 285.227222][T14882] vma_alloc_folio_noprof+0xee/0x1a0[ 285.229074][T14882] __handle_mm_fault+0x2b38/0x56a0[ 285.230822][T14882] handle_mm_fault+0x368/0x9f0...This series fixes all issues I found so far. There is no easy way to fixwithout a bigger rework/cleanup. I have a bunch of cleanups on top (someprevious sent, some the result of the discussion in v1) that I will sendout separately once this landed and I get to it.I wish we could just use some special present PROT_NONE PTEs instead ofthese (non-present, non-none) fake-swap entries; but that just results inthe same problem we keep having (lack of spare PTE bits), and staring atother similar fake-swap entries, that ship has sailed.With this series, make_device_exclusive() doesn't actually belong intomm/rmap.c anymore, but I'll leave moving that for another day.I only tested this series with the hmm-tests selftests due to lack of HW,so I'd appreciate some testing, especially if the interaction between twoGPUs wanting a device-exclusive entry works as expected.#include #include #include #include #include #include #include #include #include #include #define HMM_DMIRROR_EXCLUSIVE _IOWR('H', 0x05, struct hmm_dmirror_cmd)struct hmm_dmirror_cmd { __u64 addr; __u64 ptr; __u64 npages; __u64 cpages; __u64 faults;};const size_t size = 1 * 1024 * 1024 * 1024ul;const size_t chunk_size = 2 * 1024 * 1024ul;int m---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-22077 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Revert "smb: client: fix TCP timers deadlock after rmmod"This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock afterrmmod") is intended to fix a null-ptr-deref in LOCKDEP, which ismentioned as CVE-2024-54680, but is actually did not fix anything;The issue can be reproduced on top of it. [0]Also, it reverted the change by commit ef7134c7fc48 ("smb: client:Fix use-after-free of network namespace.") and introduced a realissue by reviving the kernel TCP socket.When a reconnect happens for a CIFS connection, the socket statetransitions to FIN_WAIT_1. Then, inet_csk_clear_xmit_timers_sync()in tcp_close() stops all timers for the socket.If an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1forever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.Usually, FIN can be retransmitted by the peer, but if the peer abortsthe connection, the issue comes into reality.I warned about this privately by pointing out the exact report [1],but the bogus fix was finally merged.So, we should not stop the timers to finally kill the connection onour side in that case, meaning we must not use a kernel socket forTCP whose sk->sk_net_refcnt is 0.The kernel socket does not have a reference to its netns to make itpossible to tear down netns without cleaning up every resource in it.For example, tunnel devices use a UDP socket internally, but we candestroy netns without removing such devices and let it completeduring exit. Otherwise, netns would be leaked when the last applicationdied.However, this is problematic for TCP sockets because TCP has timers toclose the connection gracefully even after the socket is close()d. Thelifetime of the socket and its netns is different from the lifetime ofthe underlying connection.If the socket user does not maintain the netns lifetime, the timer couldbe fired after the socket is close()d and its netns is freed up, resultingin use-after-free.Actually, we have seen so many similar issues and converted such socketsto have a reference to netns.That's why I converted the CIFS client socket to have a reference tonetns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scopeof CIFS and technically wrong in e9f2517a3e18, but **is in-scope and rightfix**.Regarding the LOCKDEP issue, we can prevent the module unload bybumping the module refcount when switching the LOCKDDEP key insock_lock_init_class_and_name(). [2]For a while, let's revert the bogus fix.Note that now we can use sk_net_refcnt_upgrade() for the socketconversion, but I'll do so later separately to make backport easy.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-23141 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accessesAcquire a lock on kvm->srcu when userspace is getting MP state to handle arather extreme edge case where "accepting" APIC events, i.e. processingpending INIT or SIPI, can trigger accesses to guest memory. If the vCPUis in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MPstate will trigger a nested VM-Exit by way of ->check_nested_events(), andemuating the nested VM-Exit can access guest memory.The splat was originally hit by syzkaller on a Google-internal kernel, andreproduced on an upstream kernel by hacking the triple_fault_event_testselftest to stuff a pending INIT, store an MSR on VM-Exit (to generate amemory access on VMX), and do vcpu_mp_state_get() to trigger the scenario. ============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted ----------------------------- include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-37821 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/eevdf: Fix se->slice being set to U64_MAX and resulting crashThere is a code path in dequeue_entities() that can set the slice of asched_entity to U64_MAX, which sometimes results in a crash.The offending case is when dequeue_entities() is called to dequeue adelayed group entity, and then the entity's parent's dequeue is delayed.In that case:1. In the if (entity_is_task(se)) else block at the beginning of dequeue_entities(), slice is set to cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX.2. The first for_each_sched_entity() loop dequeues the entity.3. If the entity was its parent's only child, then the next iteration tries to dequeue the parent.4. If the parent's dequeue needs to be delayed, then it breaks from the first for_each_sched_entity() loop _without updating slice_.5. The second for_each_sched_entity() loop sets the parent's ->slice to the saved slice, which is still U64_MAX.This throws off subsequent calculations with potentially catastrophicresults. A manifestation we saw in production was:6. In update_entity_lag(), se->slice is used to calculate limit, which ends up as a huge negative number.7. limit is used in se->vlag = clamp(vlag, -limit, limit). Because limit is negative, vlag > limit, so se->vlag is set to the same huge negative number.8. In place_entity(), se->vlag is scaled, which overflows and results in another huge (positive or negative) number.9. The adjusted lag is subtracted from se->vruntime, which increases or decreases se->vruntime by a huge number.10. pick_eevdf() calls entity_eligible()/vruntime_eligible(), which incorrectly returns false because the vruntime is so far from the other vruntimes on the queue, causing the (vruntime - cfs_rq->min_vruntime) * load calulation to overflow.11. Nothing appears to be eligible, so pick_eevdf() returns NULL.12. pick_next_entity() tries to dereference the return value of pick_eevdf() and crashes.Dumping the cfs_rq states from the core dumps with drgn showed tell-talehuge vruntime ranges and bogus vlag values, and I also traced se->slicebeing set to U64_MAX on live systems (which was usually "benign" sincethe rest of the runqueue needed to be in a particular state to crash).Fix it in dequeue_entities() by always setting slice from the firstnon-empty cfs_rq.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-37864 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: clean up FDB, MDB, VLAN entries on unbindAs explained in many places such as commit b117e1e8a86d ("net: dsa:delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written giventhe assumption that higher layers have balanced additions/deletions.As such, it only makes sense to be extremely vocal when thoseassumptions are violated and the driver unbinds with entries stillpresent.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 DSAexplicitly documents, and for the majority of DSA drivers this APIsimply causes them to go to promiscuous mode, that isn't the case forall drivers. Some have the necessary requirements for bridge bypassoperations 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 addressfilters on DSA interfaces from user space - namely macvlan for unicast,and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, thefact is that 'bridge fdb add ... self static local' also exists askernel UAPI, and might be useful to someone, even if only for a quickhack.It seems counter-productive to block that path by implementing shim.ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPPin order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() fromrunning, 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 differentangle as well. Russell King is noticing that the WARN_ON() triggers evenfor 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 aninformational print to the kernel log (to still have a way to seethat bugs exist), and some extra comments gathered from past years'experience, to justify the logic.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38036 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/vf: Perform early GT MMIO initialization to read GMDIDVFs need to communicate with the GuC to obtain the GMDID valueand existing GuC functions used for that assume that the GT hasit's MMIO members already setup. However, due to recent refactoringthe gt->mmio is initialized later, and any attempt by the VF to usexe_mmio_read|write() from GuC functions will lead to NPD crash dueto unset MMIO register address:[] xe 0000:00:02.1: [drm] Running in SR-IOV VF mode[] xe 0000:00:02.1: [drm] GT0: sending H2G MMIO 0x5507[] BUG: unable to handle page fault for address: 0000000000190240Since we are already tweaking the id and type of the primary GT tomimic it's a Media GT before initializing the GuC communication,we can also call xe_gt_mmio_init() to perform early setup of thegt->mmio which will make those GuC functions work again.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38052 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_doneSyzbot 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:3231After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_donemay 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 ns1The key of reproduction is that, simd_aead_encrypt is interrupted, leadingto crypto_simd_usable() return false. Thus, the cryptd_queue_worker istriggered, 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.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38075 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix timeout on deleted connectionNOPIN response timer may expire on a deleted connection and crash withsuch logs:Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3dBUG: Kernel NULL pointer dereference on read at 0x00000000NIP strlcpy+0x8/0xb0LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod]Call Trace: iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod] call_timer_fn+0x58/0x1f0 run_timer_softirq+0x740/0x860 __do_softirq+0x16c/0x420 irq_exit+0x188/0x1c0 timer_interrupt+0x184/0x410That is because nopin response timer may be re-started on nopin timerexpiration.Stop nopin timer before stopping the nopin response timer to be surethat no one of them will be re-started.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38091 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: check stream id dml21 wrapper to get plane_id[Why & How]Fix a false positive warning which occurs due to lack of correct checkswhen querying plane_id in DML21. This fixes the warning when performing amode1 reset (cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover):[ 35.751250] WARNING: CPU: 11 PID: 326 at /tmp/amd.PHpyAl7v/amd/amdgpu/../display/dc/dml2/dml2_dc_resource_mgmt.c:91 dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu][ 35.751434] Modules linked in: amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) amddrm_buddy(OE) amdxcp(OE) amddrm_exec(OE) amd_sched(OE) amdkcl(OE) drm_suballoc_helper drm_ttm_helper ttm drm_display_helper cec rc_core i2c_algo_bit rfcomm qrtr cmac algif_hash algif_skcipher af_alg bnep amd_atl intel_rapl_msr intel_rapl_common snd_hda_codec_hdmi snd_hda_intel edac_mce_amd snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec kvm_amd snd_hda_core snd_hwdep snd_pcm kvm snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul polyval_clmulni polyval_generic btusb ghash_clmulni_intel sha256_ssse3 btrtl sha1_ssse3 snd_seq btintel aesni_intel btbcm btmtk snd_seq_device crypto_simd sunrpc cryptd bluetooth snd_timer ccp binfmt_misc rapl snd i2c_piix4 wmi_bmof gigabyte_wmi k10temp i2c_smbus soundcore gpio_amdpt mac_hid sch_fq_codel msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 hid_generic usbhid hid crc32_pclmul igc ahci xhci_pci libahci xhci_pci_renesas video wmi[ 35.751501] CPU: 11 UID: 0 PID: 326 Comm: kworker/u64:9 Tainted: G OE 6.11.0-21-generic #21~24.04.1-Ubuntu[ 35.751504] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE[ 35.751505] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F30 05/22/2024[ 35.751506] Workqueue: amdgpu-reset-dev amdgpu_debugfs_reset_work [amdgpu][ 35.751638] RIP: 0010:dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu][ 35.751794] Code: 6d 0c 00 00 8b 84 24 88 00 00 00 41 3b 44 9c 20 0f 84 fc 07 00 00 48 83 c3 01 48 83 fb 06 75 b3 4c 8b 64 24 68 4c 8b 6c 24 40 <0f> 0b b8 06 00 00 00 49 8b 94 24 a0 49 00 00 89 c3 83 f8 07 0f 87[ 35.751796] RSP: 0018:ffffbfa3805d7680 EFLAGS: 00010246[ 35.751798] RAX: 0000000000010000 RBX: 0000000000000006 RCX: 0000000000000000[ 35.751799] RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000000[ 35.751800] RBP: ffffbfa3805d78f0 R08: 0000000000000000 R09: 0000000000000000[ 35.751801] R10: 0000000000000000 R11: 0000000000000000 R12: ffffbfa383249000[ 35.751802] R13: ffffa0e68f280000 R14: ffffbfa383249658 R15: 0000000000000000[ 35.751803] FS: 0000000000000000(0000) GS:ffffa0edbe580000(0000) knlGS:0000000000000000[ 35.751804] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 35.751805] CR2: 00005d847ef96c58 CR3: 000000041de3e000 CR4: 0000000000f50ef0[ 35.751806] PKRU: 55555554[ 35.751807] Call Trace:[ 35.751810] [ 35.751816] ? show_regs+0x6c/0x80[ 35.751820] ? __warn+0x88/0x140[ 35.751822] ? dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu][ 35.751964] ? report_bug+0x182/0x1b0[ 35.751969] ? handle_bug+0x6e/0xb0[ 35.751972] ? exc_invalid_op+0x18/0x80[ 35.751974] ? asm_exc_invalid_op+0x1b/0x20[ 35.751978] ? dml2_map_dc_pipes+0x243d/0x3f40 [amdgpu][ 35.752117] ? math_pow+0x48/0xa0 [amdgpu][ 35.752256] ? srso_alias_return_thunk+0x5/0xfbef5[ 35.752260] ? math_pow+0x48/0xa0 [amdgpu][ 35.752400] ? srso_alias_return_thunk+0x5/0xfbef5[ 35.752403] ? math_pow+0x11/0xa0 [amdgpu][ 35.752524] ? srso_alias_return_thunk+0x5/0xfbef5[ 35.752526] ? core_dcn4_mode_programming+0xe4d/0x20d0 [amdgpu][ 35.752663] ? srso_alias_return_thunk+0x5/0xfbef5[ 35.752669] dml21_validate+0x3d4/0x980 [amdgpu](cherry picked from commit f8ad62c0a93e5dd94243e10f1b742232e4d6411e)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38095 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf: insert memory barrier before updating num_fencessmp_store_mb() inserts memory barrier after storing operation.It is different with what the comment is originally aiming so Nullpointer dereference can be happened if memory update is reordered.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38096 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: don't warn when if there is a FW erroriwl_trans_reclaim is warning if it is called when the FW is not alive.But if it is called when there is a pending restart, i.e. after a FWerror, there is no need to warn, instead - return silently.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38113 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: CPPC: Fix NULL pointer dereference when nosmp is usedWith nosmp in cmdline, other CPUs are not brought up, leavingtheir 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] [] cppc_allow_fast_switch+0x6a/0xd4...Kernel panic - not syncing: Attempted to kill init![ rjw: New subject ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38119 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: ufs: Fix a hang in the error handlerufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latterfunction can only succeed if UFSHCD_EH_IN_PROGRESS is not set becauseresuming involves submitting a SCSI command and ufshcd_queuecommand()returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix thishang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() hasbeen called instead of before.Backtrace:__switch_to+0x174/0x338__schedule+0x600/0x9e4schedule+0x7c/0xe8schedule_timeout+0xa4/0x1c8io_schedule_timeout+0x48/0x70wait_for_common_io+0xa8/0x160 //waiting on START_STOPwait_for_completion_io_timeout+0x10/0x20blk_execute_rq+0xe4/0x1e4scsi_execute_cmd+0x108/0x244ufshcd_set_dev_pwr_mode+0xe8/0x250__ufshcd_wl_resume+0x94/0x354ufshcd_wl_runtime_resume+0x3c/0x174scsi_runtime_resume+0x64/0xa4rpm_resume+0x15c/0xa1c__pm_runtime_resume+0x4c/0x90 // Runtime resume ongoingufshcd_err_handler+0x1a0/0xd08process_one_work+0x174/0x808worker_thread+0x15c/0x490kthread+0xf4/0x1ecret_from_fork+0x10/0x20[ bvanassche: rewrote patch description ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38122 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: add missing NULL check for gve_alloc_pending_packet() in TX DQOgve_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 pointerdereference when allocation fails.This improves robustness in low-memory scenarios.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38123 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: wwan: t7xx: Fix napi rx poll issueWhen driver handles the napi rx polling requests, the netdev mighthave been released by the dellink logic triggered by the disconnectoperation on user plane. However, in the logic of processing skb inpolling, an invalid netdev is still being used, which causes a panic.BUG: kernel NULL pointer dereference, address: 00000000000000f1Oops: 0000 [#1] PREEMPT SMP NOPTIRIP: 0010:dev_gro_receive+0x3a/0x620[...]Call Trace: ? __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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38124 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix udp gso skb_segment after pull from frag_listCommit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation afterpull from frag_list") detected invalid geometry in frag_list skbs andredirects them from skb_segment_list to more robust skb_segment. But somepackets with modified geometry can also hit bugs in that code. We don'tknow how many such cases exist. Addressing each one by one also requirestouching the complex skb_segment code, which risks introducing bugs forother types of skbs. Instead, linearize all these packets that fail thebasic invariants on gso fraglist skbs. That is more robust.If only part of the fraglist payload is pulled into head_skb, it willalways cause exception when splitting skbs by skb_segment. For detailedcall 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_sizeOptional datapath hooks such as NAT and BPF (bpf_skb_pull_data) canmodify 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 werepulled tail to become (12,10,10) bytes.The skbs no longer meets the above SKB_GSO_FRAGLIST conditions becausepayload was pulled into head_skb, it needs to be linearized before passto 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38127 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix Tx scheduler error handling in XDP callbackWhen the XDP program is loaded, the XDP callback adds new Tx queues.This means that the callback must update the Tx scheduler with the newqueue number. In the event of a Tx scheduler failure, the XDP callbackshould also fail and roll back any changes previously made for XDPpreparation.The previous implementation had a bug that not all changes made by theXDP callback were rolled back. This caused the crash with the followingcall 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] [ +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] [ +0.002098] [ +0.002106] asm_common_interrupt+0x26/0x40[ +0.004184] RIP: 0010:cpuidle_enter_state+0xd3/0x690Fix this by performing the missing unmapping of XDP queues fromq_vectors and setting the XDP rings pointer back to NULL after all thosequeues are released.Also, add an immediate exit from the XDP callback in case of ringpreparation failure.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38134 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: acpi: Prevent null pointer dereference in usb_acpi_add_usb4_devlink()As demonstrated by the fix for update_port_device_state,commit 12783c0b9e2c ("usb: core: Prevent null pointer dereference in update_port_device_state"),usb_hub_to_struct_hub() can return NULL in certain scenarios,such as during hub driver unbind or teardown race conditions,even if the underlying usb_device structure exists.Plus, all other places that call usb_hub_to_struct_hub() in the same filedo check for NULL return values.If usb_hub_to_struct_hub() returns NULL, the subsequent access tohub->ports[udev->portnum - 1] will cause a null pointer dereference.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38136 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: renesas_usbhs: Reorder clock handling and power management in probeReorder the initialization sequence in `usbhs_probe()` to enable runtimePM before accessing registers, preventing potential crashes due touninitialized clocks.Currently, in the probe path, registers are accessed before enabling theclocks, 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 clocksSince `iowrite16()` is performed without ensuring the required clocks areenabled, this can lead to access errors. To fix this, enable PM runtimeearly in the probe function and ensure clocks are acquired before registeraccess, 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 ]---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38138 Severity: Moderate CVSS3 score: 5.5

Description: 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 NULLpointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38143 Severity: Moderate CVSS3 score: 5.5

Description: 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 NULLpointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38145 Severity: Moderate CVSS3 score: 5.5

Description: 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 aNULL pointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.[arj: Fix Fixes: tag to use subject from 3772e5da4454]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38148 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: mscc: Fix memory leak when using one step timestampingFix memory leak when running one-step timestamping. When runningone-step sync timestamping, the HW is configured to insert the TX timeinto the frame, so there is no reason to keep the skb anymore. As inthis case the HW will never generate an interrupt to say that the framewas timestamped, then the frame will never released.Fix this by freeing the frame in case of one-step timestamping.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38155 Severity: Moderate CVSS3 score: 5.5

Description: 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 pointerdereference.Prevent null pointer dereference in mt7915_mmio_wed_init().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38160 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: bcm: rpi: Add NULL check in raspberrypi_clk_register()devm_kasprintf() returns NULL when memory allocation fails. Currently,raspberrypi_clk_register() does not check for this case, which resultsin a NULL pointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38165 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix panic when calling skb_linearizeThe panic can be reproduced by executing the command:./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000Then a kernel panic was captured:'''[ 657.460555] kernel BUG at net/core/skbuff.c:2178![ 657.462680] Tainted: [W]=WARN[ 657.463287] Workqueue: events sk_psock_backlog...[ 657.469610] [ 657.469738] ? die+0x36/0x90[ 657.469916] ? do_trap+0x1d0/0x270[ 657.470118] ? pskb_expand_head+0x612/0xf40[ 657.470376] ? pskb_expand_head+0x612/0xf40[ 657.470620] ? do_error_trap+0xa3/0x170[ 657.470846] ? pskb_expand_head+0x612/0xf40[ 657.471092] ? handle_invalid_op+0x2c/0x40[ 657.471335] ? pskb_expand_head+0x612/0xf40[ 657.471579] ? exc_invalid_op+0x2d/0x40[ 657.471805] ? asm_exc_invalid_op+0x1a/0x20[ 657.472052] ? pskb_expand_head+0xd1/0xf40[ 657.472292] ? pskb_expand_head+0x612/0xf40[ 657.472540] ? lock_acquire+0x18f/0x4e0[ 657.472766] ? find_held_lock+0x2d/0x110[ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10[ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470[ 657.473537] ? __pfx___lock_release.isra.0+0x10/0x10[ 657.473826] __pskb_pull_tail+0xfd/0x1d20[ 657.474062] ? __kasan_slab_alloc+0x4e/0x90[ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510[ 657.475392] ? __kasan_kmalloc+0xaa/0xb0[ 657.476010] sk_psock_backlog+0x5cf/0xd70[ 657.476637] process_one_work+0x858/0x1a20'''The panic originates from the assertion BUG_ON(skb_shared(skb)) inskb_linearize(). A previous commit(see Fixes tag) introduced skb_get()to avoid race conditions between skb operations in the backlog and skbrelease in the recvmsg path. However, this caused the panic to alwaysoccur when skb_linearize is executed.The "--rx-strp 100000" parameter forces the RX path to use the strparsermodule which aggregates data until it reaches 100KB before calling sockmaplogic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize.To fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue.'''sk_psock_backlog: sk_psock_handle_skb skb_get(skb) <== we move it into 'sk_psock_skb_ingress_enqueue' sk_psock_skb_ingress____________ v | | -> sk_psock_skb_ingress_self | sk_psock_skb_ingress_enqueuesk_psock_verdict_apply_________________^ skb_linearize'''Note that for verdict_apply path, the skb_get operation is unnecessary sowe add 'take_ref' param to control it's behavior.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38182 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ublk: santizize the arguments from userspace when adding a deviceSanity check the values for queue depth and number of queueswe get from userspace when adding a device.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38184 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearerThe reproduction steps:1. create a tun interface2. enable l2 bearer3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tuntipc: Started in network modetipc: Node identity 8af312d38a21, cluster identity 4711tipc: Enabled bearer , priority 1Oops: general protection faultKASAN: null-ptr-deref in rangeCPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPTHardware name: QEMU Ubuntu 24.04 PCRIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0the ub was in fact a struct dev.when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL orother media when other thread changes it.fix this by checking media_id.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38185 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: atmtcp: Free invalid length skb in atmtcp_c_send().syzbot reported the splat below. [0]vcc_sendmsg() copies data passed from userspace to skb and passesit to vcc->dev->ops->send().atmtcp_c_send() accesses skb->data as struct atmtcp_hdr afterchecking if skb->len is 0, but it's not enough.Also, when skb->len == 0, skb and sk (vcc) were leaked becausedev_kfree_skb() is not called and sk_wmem_alloc adjustment is missingto revert atm_account_tx() in vcc_sendmsg(), which is expectedto be done in atm_pop_raw().Let's properly free skb with an invalid length in atmtcp_c_send().[0]:BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:670 alloc_skb include/linux/skbuff.h:1336 [inline] vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38186 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix double invocation of bnxt_ulp_stop()/bnxt_ulp_start()Before the commit under the Fixes tag below, bnxt_ulp_stop() andbnxt_ulp_start() were always invoked in pairs. After that commit,the new bnxt_ulp_restart() can be invoked after bnxt_ulp_stop()has been called. This may result in the RoCE driver's aux driver.suspend() method being invoked twice. The 2nd bnxt_re_suspend()call will crash when it dereferences a NULL pointer:(NULL ib_device): Handle device suspend callBUG: kernel NULL pointer dereference, address: 0000000000000b78PGD 0 P4D 0Oops: Oops: 0000 [#1] SMP PTICPU: 20 UID: 0 PID: 181 Comm: kworker/u96:5 Tainted: G S 6.15.0-rc1 #4 PREEMPT(voluntary)Tainted: [S]=CPU_OUT_OF_SPECHardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017Workqueue: bnxt_pf_wq bnxt_sp_task [bnxt_en]RIP: 0010:bnxt_re_suspend+0x45/0x1f0 [bnxt_re]Code: 8b 05 a7 3c 5b f5 48 89 44 24 18 31 c0 49 8b 5c 24 08 4d 8b 2c 24 e8 ea 06 0a f4 48 c7 c6 04 60 52 c0 48 89 df e8 1b ce f9 ff <48> 8b 83 78 0b 00 00 48 8b 80 38 03 00 00 a8 40 0f 85 b5 00 00 00RSP: 0018:ffffa2e84084fd88 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001RDX: 0000000000000000 RSI: ffffffffb4b6b934 RDI: 00000000ffffffffRBP: ffffa1760954c9c0 R08: 0000000000000000 R09: c0000000ffffdfffR10: 0000000000000001 R11: ffffa2e84084fb50 R12: ffffa176031ef070R13: ffffa17609775000 R14: ffffa17603adc180 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffffa17daa397000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000b78 CR3: 00000004aaa30003 CR4: 00000000003706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:bnxt_ulp_stop+0x69/0x90 [bnxt_en]bnxt_sp_task+0x678/0x920 [bnxt_en]? __schedule+0x514/0xf50process_scheduled_works+0x9d/0x400worker_thread+0x11c/0x260? __pfx_worker_thread+0x10/0x10kthread+0xfe/0x1e0? __pfx_kthread+0x10/0x10ret_from_fork+0x2b/0x40? __pfx_kthread+0x10/0x10ret_from_fork_asm+0x1a/0x30Check the BNXT_EN_FLAG_ULP_STOPPED flag and do not proceed if the flagis already set. This will preserve the original symmetricalbnxt_ulp_stop() and bnxt_ulp_start().Also, inside bnxt_ulp_start(), clear the BNXT_EN_FLAG_ULP_STOPPEDflag after taking the mutex to avoid any race condition. And forsymmetry, only proceed in bnxt_ulp_start() if theBNXT_EN_FLAG_ULP_STOPPED is set.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38188 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/a7xx: Call CP_RESET_CONTEXT_STATECalling this packet is necessary when we switch contexts because thereare various pieces of state used by userspace to synchronize between BRand BV that are persistent across submits and we need to make sure thatthey are in a "safe" state when switching contexts. Otherwise auserspace submission in one context could cause another context tofunction incorrectly and hang, effectively a denial of service (althoughwithout leaking data). This was missed during initial a7xx bringup.Patchwork: https://patchwork.freedesktop.org/patch/654924/

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38189 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Avoid NULL pointer dereference in `v3d_job_update_stats()`The following kernel Oops was recently reported by Mesa CI:[ 800.139824] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000588[ 800.148619] Mem abort info:[ 800.151402] ESR = 0x0000000096000005[ 800.155141] EC = 0x25: DABT (current EL), IL = 32 bits[ 800.160444] SET = 0, FnV = 0[ 800.163488] EA = 0, S1PTW = 0[ 800.166619] FSC = 0x05: level 1 translation fault[ 800.171487] Data abort info:[ 800.174357] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000[ 800.179832] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 800.184873] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 800.190176] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001014c2000[ 800.196607] [0000000000000588] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000[ 800.205305] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP[ 800.211564] Modules linked in: vc4 snd_soc_hdmi_codec drm_display_helper v3d cec gpu_sched drm_dma_helper drm_shmem_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm i2c_brcmstb snd_timer snd backlight[ 800.234448] 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[ 800.244182] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)[ 800.250005] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 800.256959] pc : v3d_job_update_stats+0x60/0x130 [v3d][ 800.262112] lr : v3d_job_update_stats+0x48/0x130 [v3d][ 800.267251] sp : ffffffc080003e60[ 800.270555] x29: ffffffc080003e60 x28: ffffffd842784980 x27: 0224012000000000[ 800.277687] x26: ffffffd84277f630 x25: ffffff81012fd800 x24: 0000000000000020[ 800.284818] x23: ffffff8040238b08 x22: 0000000000000570 x21: 0000000000000158[ 800.291948] x20: 0000000000000000 x19: ffffff8040238000 x18: 0000000000000000[ 800.299078] x17: ffffffa8c1bd2000 x16: ffffffc080000000 x15: 0000000000000000[ 800.306208] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000[ 800.313338] x11: 0000000000000040 x10: 0000000000001a40 x9 : ffffffd83b39757c[ 800.320468] x8 : ffffffd842786420 x7 : 7fffffffffffffff x6 : 0000000000ef32b0[ 800.327598] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : ffffffd842784980[ 800.334728] x2 : 0000000000000004 x1 : 0000000000010002 x0 : 000000ba4c0ca382[ 800.341859] Call trace:[ 800.344294] v3d_job_update_stats+0x60/0x130 [v3d][ 800.349086] v3d_irq+0x124/0x2e0 [v3d][ 800.352835] __handle_irq_event_percpu+0x58/0x218[ 800.357539] handle_irq_event+0x54/0xb8[ 800.361369] handle_fasteoi_irq+0xac/0x240[ 800.365458] handle_irq_desc+0x48/0x68[ 800.369200] generic_handle_domain_irq+0x24/0x38[ 800.373810] gic_handle_irq+0x48/0xd8[ 800.377464] call_on_irq_stack+0x24/0x58[ 800.381379] do_interrupt_handler+0x88/0x98[ 800.385554] el1_interrupt+0x34/0x68[ 800.389123] el1h_64_irq_handler+0x18/0x28[ 800.393211] el1h_64_irq+0x64/0x68[ 800.396603] default_idle_call+0x3c/0x168[ 800.400606] do_idle+0x1fc/0x230[ 800.403827] cpu_startup_entry+0x40/0x50[ 800.407742] rest_init+0xe4/0xf0[ 800.410962] start_kernel+0x5e8/0x790[ 800.414616] __primary_switched+0x80/0x90[ 800.418622] Code: 8b170277 8b160296 11000421 b9000861 (b9401ac1)[ 800.424707] ---[ end trace 0000000000000000 ]---[ 800.457313] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---This issue happens when the file descriptor is closed before the jobssubmitted by it are completed. When the job completes, we update theglobal GPU stats and the per-fd GPU stats, which are exposed throughfdinfo. If the file descriptor was closed, then the struct `v3d_file_priv`and its stats were already freed and we can't update the per-fd stats.Therefore, if the file descriptor was already closed, don't u---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38190 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: Revert atm_account_tx() if copy_from_iter_full() fails.In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc byatm_account_tx().It is expected to be reverted by atm_pop_raw() later called byvcc->dev->ops->send(vcc, skb).However, vcc_sendmsg() misses the same revert when copy_from_iter_full()fails, and then we will leak a socket.Let's factorise the revert part as atm_return_tx() and call it inthe failure path.Note that the corresponding sk_wmem_alloc operation can be found inalloc_tx() as of the blamed commit. $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38198 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: Make sure modelist not set on unregistered consoleIt looks like attempting to write to the "store_modes" sysfs node willrun afoul of unregistered consoles:UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28index -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:2439static 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 againstexisting "info" pointers, so error handling should kick in correctly.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38201 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAXOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()when resizing hashtable because __GFP_NOWARN is unset.Similar to: b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38205 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Avoid divide by zero by initializing dummy pitch to 1[Why]If the dummy values in `populate_dummy_dml_surface_cfg()` aren't updatedthen they can lead to a divide by zero in downstream callers likeCalculateVMAndRowBytes()[How]Initialize dummy value to a value to avoid divide by zero.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38208 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: add NULL check in automount_fullpathpage is checked for null in __build_path_from_dentry_optional_prefixwhen tcon->origin_fullpath is not set. However, the check is missing whenit is set.Add a check to prevent a potential NULL pointer dereference.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38214 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_varIf fb_add_videomode() in fb_set_var() fails to allocate memory forfb_videomode, later it may lead to a null-ptr dereference infb_videomode_to_var(), as the fb_info is registered while not having themode in modelist that is expected to be there, i.e. the one that isdescribed in fb_info->var.================================================================general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901Call 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(), andthen fb_videomode_to_var() is called. If it fails to add the mode tofb_info->modelist, fb_set_var() returns error, but does not restore theold value of fb_info->var. Restore fb_info->var on failure the same wayit is done earlier in the function.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38225 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Cleanup after an allocation errorWhen allocation failures are not cleaned up by the driver, furtherallocation errors will be false-positives, which will cause buffers toremain uninitialized and cause NULL pointer dereferences.Ensure proper cleanup of failed allocations to prevent these issues.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38233 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc64/ftrace: fix clobbered r15 during livepatchingWhile r15 is clobbered always with PPC_FTRACE_OUT_OF_LINE, it isnot restored in livepatch sequence leading to not so obvious failslike below: BUG: Unable to handle kernel data access on write at 0xc0000000000f9078 Faulting instruction address: 0xc0000000018ff958 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP: c0000000018ff958 LR: c0000000018ff930 CTR: c0000000009c0790 REGS: c00000005f2e7790 TRAP: 0300 Tainted: G K (6.14.0+) MSR: 8000000000009033 CR: 2822880b XER: 20040000 CFAR: c0000000008addc0 DAR: c0000000000f9078 DSISR: 0a000000 IRQMASK: 1 GPR00: c0000000018f2584 c00000005f2e7a30 c00000000280a900 c000000017ffa488 GPR04: 0000000000000008 0000000000000000 c0000000018f24fc 000000000000000d GPR08: fffffffffffe0000 000000000000000d 0000000000000000 0000000000008000 GPR12: c0000000009c0790 c000000017ffa480 c00000005f2e7c78 c0000000000f9070 GPR16: c00000005f2e7c90 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 c00000005f3efa80 c00000005f2e7c60 c00000005f2e7c88 GPR24: c00000005f2e7c60 0000000000000001 c0000000000f9078 0000000000000000 GPR28: 00007fff97960000 c000000017ffa480 0000000000000000 c0000000000f9078 ... Call Trace: check_heap_object+0x34/0x390 (unreliable) __mutex_unlock_slowpath.isra.0+0xe4/0x230 seq_read_iter+0x430/0xa90 proc_reg_read_iter+0xa4/0x200 vfs_read+0x41c/0x510 ksys_read+0xa4/0x190 system_call_exception+0x1d0/0x440 system_call_vectored_common+0x15c/0x2ecFix it by restoring r15 always.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38246 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bnxt: properly flush XDP redirect listsWe encountered following crash when testing a XDP_REDIRECT featurein production:[56251.579676] list_add corruption. next->prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd40f30).[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] [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] [56252.044246] [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---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38251 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: prevent NULL deref in clip_push()Blamed commit missed that vcc_destroy_socket() callsclip_push() with a NULL skb.If clip_devs is NULL, clip_push() then crashes when readingskb->truesize.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38255 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly()While testing null_blk with configfs, echo 0 > poll_queues will triggerfollowing panic:BUG: kernel NULL pointer dereference, address: 0000000000000010Oops: Oops: 0000 [#1] SMP NOPTICPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014RIP: 0010:__bitmap_or+0x48/0x70Call Trace: __group_cpus_evenly+0x822/0x8c0 group_cpus_evenly+0x2d9/0x490 blk_mq_map_queues+0x1e/0x110 null_map_queues+0xc9/0x170 [null_blk] blk_mq_update_queue_map+0xdb/0x160 blk_mq_update_nr_hw_queues+0x22b/0x560 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_poll_queues_store+0xa4/0x130 [null_blk] configfs_write_iter+0x109/0x1d0 vfs_write+0x26e/0x6f0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x45c4/0x45f0 do_syscall_64+0xa5/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7eRoot cause is that numgrps is set to 0, and ZERO_SIZE_PTR is returned fromkcalloc(), and later ZERO_SIZE_PTR will be deferenced.Fix the problem by checking numgrps first in group_cpus_evenly(), andreturn NULL directly if numgrps is zero.[yukuai3@huawei.com: also fix the non-SMP version]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38259 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: wcd9335: Fix missing free of regulator suppliesDriver gets and enables all regulator supplies in probe path(wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanupin final error paths and in unbind (missing remove() callback). Thisleads to leaked memory and unbalanced regulator enable count duringprobe errors or unbind.Fix this by converting entire code into devm_regulator_bulk_get_enable()which also greatly simplifies the code.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38263 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bcache: fix NULL pointer in cache_set_flush()1. LINE#1794 - LINE#1887 is some codes about function of bch_cache_set_alloc().2. LINE#2078 - LINE#2142 is some codes about function of register_cache_set().3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098. 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb) 1795 { ... 1860 if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) || 1861 mempool_init_slab_pool(&c->search, 32, bch_search_cache) || 1862 mempool_init_kmalloc_pool(&c->bio_meta, 2, 1863 sizeof(struct bbio) + sizeof(struct bio_vec) * 1864 bucket_pages(c)) || 1865 mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) || 1866 bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio), 1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) || 1868 !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) || 1869 !(c->moving_gc_wq = alloc_workqueue("bcache_gc", 1870 WQ_MEM_RECLAIM, 0)) || 1871 bch_journal_alloc(c) || 1872 bch_btree_cache_alloc(c) || 1873 bch_open_buckets_alloc(c) || 1874 bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages))) 1875 goto err; ^^^^^^^^ 1876 ... 1883 return c; 1884 err: 1885 bch_cache_set_unregister(c); ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1886 return NULL; 1887 } ... 2078 static const char *register_cache_set(struct cache *ca) 2079 { ... 2098 c = bch_cache_set_alloc(&ca->sb); 2099 if (!c) 2100 return err; ^^^^^^^^^^ ... 2128 ca->set = c; 2129 ca->set->cache[ca->sb.nr_this_dev] = ca; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... 2138 return NULL; 2139 err: 2140 bch_cache_set_unregister(c); 2141 return err; 2142 }(1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and call bch_cache_set_unregister()(LINE#1885).(2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return.(3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the value to c->cache[], it means that c->cache[] is NULL.LINE#1624 - LINE#1665 is some codes about function of cache_set_flush().As (1), in LINE#1885 callbch_cache_set_unregister()---> bch_cache_set_stop() ---> closure_queue() -.-> cache_set_flush() (as below LINE#1624) 1624 static void cache_set_flush(struct closure *cl) 1625 { ... 1654 for_each_cache(ca, c, i) 1655 if (ca->alloc_thread) ^^ 1656 kthread_stop(ca->alloc_thread); ... 1665 }(4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the kernel crash occurred as below:[ 846.712887] bcache: register_cache() error drbd6: cannot allocate memory[ 846.713242] bcache: register_bcache() error : failed to register device[ 846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered[ 846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8[ 846.714790] PGD 0 P4D 0[ 846.715129] Oops: 0000 [#1] SMP PTI[ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G OE --------- - - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1[ 846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018[ 846.716451] Workqueue: events cache_set_flush [bcache][ 846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache][ 846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 0---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38264 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: sanitize request list handlingValidate the request in nvme_tcp_handle_r2t() to ensure it's not part ofany list, otherwise a malicious R2T PDU might inject a loop in requestlist processing.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38265 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: jsm: fix NPE during jsm_uart_port_initNo device was set which caused serial_base_ctrl_add to crash. BUG: kernel NULL pointer dereference, address: 0000000000000050 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 16 UID: 0 PID: 368 Comm: (udev-worker) Not tainted 6.12.25-amd64 #1 Debian 6.12.25-1 RIP: 0010:serial_base_ctrl_add+0x96/0x120 Call Trace: serial_core_register_port+0x1a0/0x580 ? __setup_irq+0x39c/0x660 ? __kmalloc_cache_noprof+0x111/0x310 jsm_uart_port_init+0xe8/0x180 [jsm] jsm_probe_one+0x1f4/0x410 [jsm] local_pci_probe+0x42/0x90 pci_device_probe+0x22f/0x270 really_probe+0xdb/0x340 ? pm_runtime_barrier+0x54/0x90 ? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8c/0xe0 bus_add_driver+0x112/0x1f0 driver_register+0x72/0xd0 jsm_init_module+0x36/0xff0 [jsm] ? __pfx_jsm_init_module+0x10/0x10 [jsm] do_one_initcall+0x58/0x310 do_init_module+0x60/0x230Tested with Digi Neo PCIe 8 port card.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38272 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: b53: do not enable EEE on bcm63xxBCM63xx internal switches do not support EEE, but provide multiple RGMIIports where external PHYs may be connected. If one of these PHYs are EEEcapable, we may try to enable EEE for the MACs, which then hangs thesystem on access of the (non-existent) EEE registers.Fix this by checking if the switch actually supports EEE beforeattempting to configure it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38275 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bugThe qmp_usb_iomap() helper function currently returns the raw result ofdevm_ioremap() for non-exclusive mappings. Since devm_ioremap() may returna 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.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38278 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: QOS: Refactor TC_HTB_LEAF_DEL_LAST callbackThis patch addresses below issues,1. Active traffic on the leaf node must be stopped before its send queue is reassigned to the parent. This patch resolves the issue by marking the node as 'Inner'.2. During a system reboot, the interface receives TC_HTB_LEAF_DEL and TC_HTB_LEAF_DEL_LAST callbacks to delete its HTB queues. In the case of TC_HTB_LEAF_DEL_LAST, although the same send queue is reassigned to the parent, the current logic still attempts to update the real number of queues, leadning to below warnings New queues can't be registered after device unregistration. WARNING: CPU: 0 PID: 6475 at net/core/net-sysfs.c:1714 netdev_queue_update_kobjects+0x1e4/0x200

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38287 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:IB/cm: Drop lockdep assert and WARN when freeing old msgThe send completion handler can run after cm_id has advanced to anothermessage. The cm_id lock is not needed in this case, but a recent changere-used cm_free_priv_msg(), which asserts that the lock is held andWARNs if the cm_id's currently outstanding msg is different than the onebeing freed.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38288 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Fix smp_processor_id() call trace for preemptible kernelsCorrect kernel call trace when calling smp_processor_id() when called inpreemptible kernels by using raw_smp_processor_id().smp_processor_id() checks to see if preemption is disabled and if not,issue an error message followed by a call to dump_stack().Brief example of call trace:kernel: check_preemption_disabled: 436 callbacks suppressedkernel: BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u1025:0/2354kernel: caller is pqi_scsi_queue_command+0x183/0x310 [smartpqi]kernel: CPU: 129 PID: 2354 Comm: kworker/u1025:0kernel: ...kernel: Workqueue: writeback wb_workfn (flush-253:0)kernel: Call Trace:kernel: kernel: dump_stack_lvl+0x34/0x48kernel: check_preemption_disabled+0xdd/0xe0kernel: pqi_scsi_queue_command+0x183/0x310 [smartpqi]kernel: ...

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38299 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMP_DUMMY()ETDM2_IN_BE and ETDM1_OUT_BE are defined as COMP_EMPTY(),in the case the codec dai_name will be null.Avoid a crash if the device tree is not assigning a codecto these links.[ 1.179936] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000[ 1.181065] Mem abort info:[ 1.181420] ESR = 0x0000000096000004[ 1.181892] EC = 0x25: DABT (current EL), IL = 32 bits[ 1.182576] SET = 0, FnV = 0[ 1.182964] EA = 0, S1PTW = 0[ 1.183367] FSC = 0x04: level 0 translation fault[ 1.183983] Data abort info:[ 1.184406] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 1.185097] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 1.185766] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 1.186439] [0000000000000000] user address but active_mm is swapper[ 1.187239] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 1.188029] Modules linked in:[ 1.188420] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85[ 1.189515] Hardware name: Radxa NIO 12L (DT)[ 1.190065] Workqueue: events_unbound deferred_probe_work_func[ 1.190808] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 1.191683] pc : __pi_strcmp+0x24/0x140[ 1.192170] lr : mt8195_mt6359_soc_card_probe+0x224/0x7b0[ 1.192854] sp : ffff800083473970[ 1.193271] x29: ffff800083473a10 x28: 0000000000001008 x27: 0000000000000002[ 1.194168] x26: ffff800082408960 x25: ffff800082417db0 x24: ffff800082417d88[ 1.195065] x23: 000000000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8[ 1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00000000ffffffff[ 1.196858] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000006[ 1.197755] x14: ffff800082407af0 x13: 6e6f69737265766e x12: 692d6b636f6c6374[ 1.198651] x11: 0000000000000002 x10: ffff80008240b920 x9 : 0000000000000018[ 1.199547] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000[ 1.200443] x5 : 0000000000000000 x4 : 8080808080000000 x3 : 303933383978616d[ 1.201339] x2 : 0000000000000000 x1 : ffff80008240b920 x0 : 0000000000000000[ 1.202236] Call trace:[ 1.202545] __pi_strcmp+0x24/0x140 (P)[ 1.203029] mtk_soundcard_common_probe+0x3bc/0x5b8[ 1.203644] platform_probe+0x70/0xe8[ 1.204106] really_probe+0xc8/0x3a0[ 1.204556] __driver_probe_device+0x84/0x160[ 1.205104] driver_probe_device+0x44/0x130[ 1.205630] __device_attach_driver+0xc4/0x170[ 1.206189] bus_for_each_drv+0x8c/0xf8[ 1.206672] __device_attach+0xa8/0x1c8[ 1.207155] device_initial_probe+0x1c/0x30[ 1.207681] bus_probe_device+0xb0/0xc0[ 1.208165] deferred_probe_work_func+0xa4/0x100[ 1.208747] process_one_work+0x158/0x3e0[ 1.209254] worker_thread+0x2c4/0x3e8[ 1.209727] kthread+0x134/0x1f0[ 1.210136] ret_from_fork+0x10/0x20[ 1.210589] Code: 54000401 b50002c6 d503201f f86a6803 (f8408402)[ 1.211355] ---[ end trace 0000000000000000 ]---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38301 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvmem: zynqmp_nvmem: unbreak driver after cleanupCommit 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup")changed the driver to expect the device pointer to be passed as the"context", but in nvmem the context parameter comes from nvmem_config.privwhich is never set - Leading to null pointer exceptions when the device isaccessed.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38304 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix NULL pointer deference on eir_get_service_dataThe len parameter is considered optional so it can be NULL so it cannotbe used for skipping to next entry of EIR_SERVICE_DATA.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38305 Severity: Moderate CVSS3 score: 5.5

Description: 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_clockand 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 inptp_vclock_in_use(), we observe a recursive lock in the call tracestarting from n_vclocks_store().============================================WARNING: possible recursive locking detected6.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:415but task is already holding lock:ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215other 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 checksptp->n_vclocks in ptp_vclock_in_use().The reason why this is appropriate is that any path that usesptp->n_vclocks must unconditionally check if ptp->n_vclocks is greaterthan 0 before unregistering vclocks, and all functions are alreadywritten this way. And in the function that uses ptp->n_vclocks, wealready get ptp->n_vclocks_mux before unregistering vclocks.Therefore, we need to remove the redundant check for ptp->n_vclocks inptp_vclock_in_use() to prevent recursive locking.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38307 Severity: Moderate CVSS3 score: 5.5

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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38313 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: fix double-free on mc_devThe 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 themc_dev variable is just a reference to one of its fields. In thiscircumstance, on the error path only the mc_bus should be freed.This commit introduces back the following checkpatch warning which is afalse-positive.WARNING: kfree(NULL) is safe and this check is probably not required+ if (mc_bus)+ kfree(mc_bus);

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38319 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_tableThe function atomctrl_initialize_mc_reg_table() andatomctrl_initialize_mc_reg_table_v2_2() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table()fails to retrieve vram_info, it returns NULL which is laterdereferenced.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38326 Severity: Moderate CVSS3 score: 5.5

Description: 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 arewaiting to be transmitted to the aoe target. This queue was added aspart of the conversion to blk_mq. However, the queue was not cleaned outwhen an aoe device is downed which caused blk_mq_freeze_queue() to sleepindefinitely waiting for those requests to complete, causing a hang. Thisfix cleans out the queue before calling blk_mq_freeze_queue().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38332 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Use memcpy() for BIOS versionThe strlcat() with FORTIFY support is triggering a panic because itthinks the target buffer will overflow although the correct targetbuffer size is passed in.Anyway, instead of memset() with 0 followed by a strlcat(), just usememcpy() and ensure that the resulting buffer is NULL terminated.BIOSVersion is only used for the lpfc_printf_log() which expects aproperly terminated string.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38335 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: gpio-keys - fix a sleep while atomic with PREEMPT_RTWhen enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs inhard irq context, but the input_event() takes a spin_lock, which isn'tallowed 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/0xccConsidering the gpio_keys_irq_isr() can run in any context, e.g. it canbe threaded, it seems there's no point in requesting the timer isr torun in hard irq context.Relax the hrtimer not to use the hard context.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38337 Severity: Moderate CVSS3 score: 5.5

Description: 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 itto 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_metadatawrite 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.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38341 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:eth: fbnic: avoid double free when failing to DMA-map FW msgThe semantics are that caller of fbnic_mbx_map_msg() retainsthe ownership of the message on error. All existing callersdutifully free the page.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38344 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: fix acpi parse and parseext cache leaksACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5I'm Seunghun Han, and I work for National Security Research Institute ofSouth Korea.I have been doing a research on ACPI and found an ACPI cache leak in ACPIearly 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 W4.12.0-rc4-next-20170608+ #10[ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_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/0x30I 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 sameslab cache size.I finally found "Acpi-Parse" cache and "Acpi-parse_ext" cache were leakedusing 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 W4.12.0-rc4-next-20170608+ #8[ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_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 W4.12.0-rc4-next-20170608+ #8[ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_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---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38351 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flushIn KVM guests with Hyper-V hypercalls enabled, the hypercallsHVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EXallow a guest to request invalidation of portions of a virtual TLB.For this, the hypercall parameter includes a list of GVAs that are supposedto be invalidated.However, when non-canonical GVAs are passed, there is currently nofiltering in place and they are eventually passed to checked invocations ofINVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignoresnon-canonical addresses (effectively a no-op), Intel's INVVPID explicitlysignals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error(): invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel] Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel] Call Trace: vmx_flush_tlb_gva+0x320/0x490 [kvm_intel] kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]Hyper-V documents that invalid GVAs (those that are beyond a partition'sGVA space) are to be ignored. While not completely clear whether thisruling also applies to non-canonical GVAs, it is likely fine to make thatassumption, and manual testing on Azure confirms "real" Hyper-V interpretsthe specification in the same way.Skip non-canonical GVAs when processing the list of address to avoidtripping the INVVPID failure. Alternatively, KVM could filter out "bad"GVAs before inserting into the FIFO, but practically speaking the onlydownside of pushing validation to the final processing is that doing sois suboptimal for the guest, and no well-behaved guest will request TLBflushes for non-canonical addresses.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38353 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: Fix taking invalid lock on wedgeIf device wedges on e.g. GuC upload, the submission is not yet enabledand the state is not even initialized. Protect the wedge call so it doesnothing in this case. It fixes the following splat: [] xe 0000:bf:00.0: [drm] device wedged, needs recovery [] ------------[ cut here ]------------ [] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [] WARNING: CPU: 48 PID: 312 at kernel/locking/mutex.c:564 __mutex_lock+0x8a1/0xe60 ... [] RIP: 0010:__mutex_lock+0x8a1/0xe60 [] mutex_lock_nested+0x1b/0x30 [] xe_guc_submit_wedge+0x80/0x2b0 [xe]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38359 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/mm: Fix in_atomic() handling in do_secure_storage_access()Kernel user spaces accesses to not exported pages in atomic contextincorrectly try to resolve the page fault.With debug options enabled call traces like this can be seen:BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39preempt_count: 1, expected: 0RCU nest depth: 0, expected: 0INFO: lockdep is turned off.Preemption disabled at:[<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39Tainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPTTainted: [W]=WARNHardware name: IBM 3931 A01 703 (LPAR)Call Trace: [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8 [<00000383e99bf152>] __might_resched+0x292/0x2d0 [<00000383eaa7c374>] down_read+0x34/0x2d0 [<00000383e99432f8>] do_secure_storage_access+0x108/0x360 [<00000383eaa724b0>] __do_pgm_check+0x130/0x220 [<00000383eaa842e4>] pgm_check_handler+0x114/0x160 [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0) [<00000383e9c45eae>] generic_perform_write+0x16e/0x310 [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160 [<00000383e9da0de4>] vfs_write+0x1c4/0x460 [<00000383e9da123c>] ksys_write+0x7c/0x100 [<00000383eaa7284e>] __do_syscall+0x15e/0x280 [<00000383eaa8417e>] system_call+0x6e/0x90INFO: lockdep is turned off.It is not allowed to take the mmap_lock while in atomic context. Thereforehandle such a secure storage access fault as if the accessed page is notmapped: the uaccess function will return -EFAULT, and the caller has todeal with this. Usually this means that the access is retried in processcontext, which allows to resolve the page fault (or in this case export thepage).

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38360 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add more checks for DSC / HUBP ONO guarantees[WHY]For non-zero DSC instances it's possible that the HUBP domain requiredto drive it for sequential ONO ASICs isn't met, potentially causingthe logic to the tile to enter an undefined state leading to a systemhang.[HOW]Add more checks to ensure that the HUBP domain matching the DSC instanceis appropriately powered.(cherry picked from commit da63df07112e5a9857a8d2aaa04255c4206754ec)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38361 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check dce_hwseq before dereferencing it[WHAT]hws was checked for null earlier in dce110_blank_stream, indicating hwscan be null, and should be checked whenever it is used.(cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38362 Severity: Moderate CVSS3 score: 5.5

Description: 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 functionget_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 inmod_hdcp_hdcp2_enable_encryption().Add a null pointer check for get_first_active_display() and returnMOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38363 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: Fix a possible null pointer dereferenceIn tegra_crtc_reset(), new memory is allocated with kzalloc(), butno check is performed. Before calling __drm_atomic_helper_crtc_reset,state should be checked to prevent possible null pointer dereference.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38364 Severity: Moderate CVSS3 score: 5.5

Description: 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 requestingallocations. Pre-existing allocations are already counted against therequest through mas_node_count_gfp(), but the allocations will not happenif the MA_STATE_PREALLOC flag is set. This flag is meant to avoidre-allocating in bulk allocation mode, and to detect issues withpreallocation calculations.The MA_STATE_PREALLOC flag should also always be set on zero allocationsso that detection of underflow allocations will print a WARN_ON() duringconsumption.User visible effect of this flaw is a WARN_ON() followed by a null pointerdereference when subsequent requests for larger number of nodes isignored, such as the vma merge retry in mmap_region() caused by driversaltering the vma flags (which happens in v6.6, at least)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38368 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:misc: tps6594-pfsm: Add NULL pointer check in tps6594_pfsm_probe()The returned value, pfsm->miscdev.name, from devm_kasprintf()could be NULL.A pointer check is added to prevent potential NULL pointer dereference.This is similar to the fix in commit 3027e7b15b02("ice: Fix some null pointer dereference issues in ice_ptp.c").This issue is found by our static analysis tool.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38369 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before usingRunning IDXD workloads in a container with the /dev directory mounted cantrigger a call trace or even a kernel panic when the parent process of thecontainer is terminated.This issue occurs because, under certain configurations, Docker does notproperly propagate the mount replica back to the original mount point.In this case, when the user driver detaches, the WQ is destroyed but itstill 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.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38371 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Disable interrupts before resetting the GPUCurrently, an interrupt can be triggered during a GPU reset, which canlead to GPU hangs and NULL pointer dereference in an interrupt contextas 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---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38374 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:optee: ffa: fix sleep in atomic contextThe OP-TEE driver registers the function notif_callback() for FF-Anotifications. However, this function is called in an atomic contextleading to errors like this when processing asynchronous notifications: | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0-00019-g657536ebe0aa #13 | Hardware name: linux,dummy-virt (DT) | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | optee_get_msg_arg+0x7c/0x21c | simple_call_with_arg+0x50/0xc0 | optee_do_bottom_half+0x14/0x20 | notif_callback+0x3c/0x48 | handle_notif_callbacks+0x9c/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20Fix this by adding work queue to process the notification in anon-atomic context.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38376 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: chipidea: udc: disconnect/reconnect from host when do suspend/resumeShawn 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 busis still active which caused the USB host continues to transfer data withdevice and the device continues to queue USB requests (in this case, adelayed TCP ACK packet trigger the issue) after controller is suspended,however the USB controller clock is already gated off. Then if udc driveraccess registers after that point, the system will hang.The correct way to avoid such issue is to disconnect device from host whenthe USB bus is not at suspend state. Then the host will receive disconnectevent and stop data transfer in time. To continue make USB gadget devicework after system resume, this will reconnect device automatically.To make usb wakeup work if USB bus is already at suspend state, this willkeep connection for it only when USB device controller has enabled wakeupcapability.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38381 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: cs40l50-vibra - fix potential NULL dereference in cs40l50_upload_owt()The cs40l50_upload_owt() function allocates memory via kmalloc()without checking for allocation failure, which could lead to aNULL pointer dereference.Return -ENOMEM in case allocation fails.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38386 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Refuse to evaluate a method if arguments are missingAs reported in [1], a platform firmware update that increased the numberof 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 fixedup by the interpreter (it cannot produce missing data out of thin air),address it by making ACPICA refuse to evaluate a method if the callerattempts to pass fewer arguments than expected to it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38389 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Fix timeline left held on VMA alloc errorThe following error has been reported sporadically by CI when a testunbinds 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] <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 theerror 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 unbindattempt.All of the above tests perform actions which are actively interrupted withsignals. Further debugging has allowed to narrow that scope down toDRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ringsubmission, in particular.If successful then that function, or its execlists or GuC submissionequivalent, is supposed to be called only once per GEM context engine,followed by raise of a flag that prevents the function from being calledagain. The function is expected to unwind its internal errors itself, soit may be safely called once more after it returns an error.In case of ring submission, the function first gets a reference to theengine's legacy timeline and then allocates a VMA. If the VMA allocationfails, e.g. when i915_vma_instance() called from inside is interruptedwith a signal, then ring_context_alloc() fails, leaving the timeline heldreferenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to thetimeline is got, and only that last one is put on successful completion.As a consequence, the legacy timeline, with its underlying engine statuspage's VMA object, is still held and not released on driver unbind.Get the legacy timeline only after successful allocation of the contextengine'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)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38390 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_ffa: Fix memory leak by freeing notifier callback nodeCommit e0573444edbf ("firmware: arm_ffa: Add interfaces to requestnotification callbacks") adds support for notifier callbacks by allocatingand inserting a callback node into a hashtable during registration ofnotifiers. However, during unregistration, the code only removes thenode from the hashtable without freeing the associated memory, resultingin a memory leak.Resolve the memory leak issue by ensuring the allocated notifier callbacknode is properly freed after it is removed from the hashtable entry.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38392 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: convert control queue mutex to a spinlockWith VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generatedon 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] [] __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] [ 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/0x21e0The 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 newlock are safe except freeing the DMA memory, which may use vunmap(). Fixby requesting a contiguous physical memory for the DMA mapping.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38397 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-multipath: fix suspicious RCU usage warningWhen I run the NVME over TCP test in virtme-ng, I get the following"suspicious RCU usage" warning in nvme_mpath_add_sysfs_link():'''[ 5.024557][ T44] nvmet: Created nvm controller 1 for subsystem nqn.2025-06.org.nvmexpress.mptcp for NQN nqn.2014-08.org.nvmexpress:uuid:f7f6b5e0-ff97-4894-98ac-c85309e0bc77.[ 5.027401][ T183] nvme nvme0: creating 2 I/O queues.[ 5.029017][ T183] nvme nvme0: mapped 2/0/0 default/read/poll queues.[ 5.032587][ T183] nvme nvme0: new ctrl: NQN "nqn.2025-06.org.nvmexpress.mptcp", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:f7f6b5e0-ff97-4894-98ac-c85309e0bc77[ 5.042214][ T25][ 5.042440][ T25] =============================[ 5.042579][ T25] WARNING: suspicious RCU usage[ 5.042705][ T25] 6.16.0-rc3+ #23 Not tainted[ 5.042812][ T25] -----------------------------[ 5.042934][ T25] drivers/nvme/host/multipath.c:1203 RCU-list traversed in non-reader section!![ 5.043111][ T25][ 5.043111][ T25] other info that might help us debug this:[ 5.043111][ T25][ 5.043341][ T25][ 5.043341][ T25] rcu_scheduler_active = 2, debug_locks = 1[ 5.043502][ T25] 3 locks held by kworker/u9:0/25:[ 5.043615][ T25] #0: ffff888008730948 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x7ed/0x1350[ 5.043830][ T25] #1: ffffc900001afd40 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0xcf3/0x1350[ 5.044084][ T25] #2: ffff888013ee0020 (&head->srcu){.+.+}-{0:0}, at: nvme_mpath_add_sysfs_link.part.0+0xb4/0x3a0[ 5.044300][ T25][ 5.044300][ T25] stack backtrace:[ 5.044439][ T25] CPU: 0 UID: 0 PID: 25 Comm: kworker/u9:0 Not tainted 6.16.0-rc3+ #23 PREEMPT(full)[ 5.044441][ T25] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011[ 5.044442][ T25] Workqueue: async async_run_entry_fn[ 5.044445][ T25] Call Trace:[ 5.044446][ T25] [ 5.044449][ T25] dump_stack_lvl+0x6f/0xb0[ 5.044453][ T25] lockdep_rcu_suspicious.cold+0x4f/0xb1[ 5.044457][ T25] nvme_mpath_add_sysfs_link.part.0+0x2fb/0x3a0[ 5.044459][ T25] ? queue_work_on+0x90/0xf0[ 5.044461][ T25] ? lockdep_hardirqs_on+0x78/0x110[ 5.044466][ T25] nvme_mpath_set_live+0x1e9/0x4f0[ 5.044470][ T25] nvme_mpath_add_disk+0x240/0x2f0[ 5.044472][ T25] ? __pfx_nvme_mpath_add_disk+0x10/0x10[ 5.044475][ T25] ? add_disk_fwnode+0x361/0x580[ 5.044480][ T25] nvme_alloc_ns+0x81c/0x17c0[ 5.044483][ T25] ? kasan_quarantine_put+0x104/0x240[ 5.044487][ T25] ? __pfx_nvme_alloc_ns+0x10/0x10[ 5.044495][ T25] ? __pfx_nvme_find_get_ns+0x10/0x10[ 5.044496][ T25] ? rcu_read_lock_any_held+0x45/0xa0[ 5.044498][ T25] ? validate_chain+0x232/0x4f0[ 5.044503][ T25] nvme_scan_ns+0x4c8/0x810[ 5.044506][ T25] ? __pfx_nvme_scan_ns+0x10/0x10[ 5.044508][ T25] ? find_held_lock+0x2b/0x80[ 5.044512][ T25] ? ktime_get+0x16d/0x220[ 5.044517][ T25] ? kvm_clock_get_cycles+0x18/0x30[ 5.044520][ T25] ? __pfx_nvme_scan_ns_async+0x10/0x10[ 5.044522][ T25] async_run_entry_fn+0x97/0x560[ 5.044523][ T25] ? rcu_is_watching+0x12/0xc0[ 5.044526][ T25] process_one_work+0xd3c/0x1350[ 5.044532][ T25] ? __pfx_process_one_work+0x10/0x10[ 5.044536][ T25] ? assign_work+0x16c/0x240[ 5.044539][ T25] worker_thread+0x4da/0xd50[ 5.044545][ T25] ? __pfx_worker_thread+0x10/0x10[ 5.044546][ T25] kthread+0x356/0x5c0[ 5.044548][ T25] ? __pfx_kthread+0x10/0x10[ 5.044549][ T25] ? ret_from_fork+0x1b/0x2e0[ 5.044552][ T25] ? __lock_release.isra.0+0x5d/0x180[ 5.044553][ T25] ? ret_from_fork+0x1b/0x2e0[ 5.044555][ T25] ? rcu_is_watching+0x12/0xc0[ 5.044557][ T25] ? __pfx_kthread+0x10/0x10[ 5.04---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38399 Severity: Moderate CVSS3 score: 5.5

Description: 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 thedest_se_deve pointer, which may be NULL.This can lead to a NULL pointer dereference if dest_se_deve remainsunset.SPC-3 PR SPEC_I_PT: Unable to locate dest_tpgUnable to handle kernel paging request at virtual address dfff800000000012Call 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 callingcore_scsi3_lunacl_undepend_item()

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38402 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: return 0 size for RSS key if not supportedReturning -EOPNOTSUPP from function returning u32 is leading tocast and invalid size value as a result.-EOPNOTSUPP as a size probably will lead to allocation fail.Command: ethtool -x eth0It is visible on all devices that don't have RSS caps set.[ 136.615917] Call Trace:[ 136.615921] [ 136.615927] ? __warn+0x89/0x130[ 136.615942] ? __alloc_frozen_pages_noprof+0x322/0x330[ 136.615953] ? report_bug+0x164/0x190[ 136.615968] ? handle_bug+0x58/0x90[ 136.615979] ? exc_invalid_op+0x17/0x70[ 136.615987] ? asm_exc_invalid_op+0x1a/0x20[ 136.616001] ? rss_prepare_get.constprop.0+0xb9/0x170[ 136.616016] ? __alloc_frozen_pages_noprof+0x322/0x330[ 136.616028] __alloc_pages_noprof+0xe/0x20[ 136.616038] ___kmalloc_large_node+0x80/0x110[ 136.616072] __kmalloc_large_node_noprof+0x1d/0xa0[ 136.616081] __kmalloc_noprof+0x32c/0x4c0[ 136.616098] ? rss_prepare_get.constprop.0+0xb9/0x170[ 136.616105] rss_prepare_get.constprop.0+0xb9/0x170[ 136.616114] ethnl_default_doit+0x107/0x3d0[ 136.616131] genl_family_rcv_msg_doit+0x100/0x160[ 136.616147] genl_rcv_msg+0x1b8/0x2c0[ 136.616156] ? __pfx_ethnl_default_doit+0x10/0x10[ 136.616168] ? __pfx_genl_rcv_msg+0x10/0x10[ 136.616176] netlink_rcv_skb+0x58/0x110[ 136.616186] genl_rcv+0x28/0x40[ 136.616195] netlink_unicast+0x19b/0x290[ 136.616206] netlink_sendmsg+0x222/0x490[ 136.616215] __sys_sendto+0x1fd/0x210[ 136.616233] __x64_sys_sendto+0x24/0x30[ 136.616242] do_syscall_64+0x82/0x160[ 136.616252] ? __sys_recvmsg+0x83/0xe0[ 136.616265] ? syscall_exit_to_user_mode+0x10/0x210[ 136.616275] ? do_syscall_64+0x8e/0x160[ 136.616282] ? __count_memcg_events+0xa1/0x130[ 136.616295] ? count_memcg_events.constprop.0+0x1a/0x30[ 136.616306] ? handle_mm_fault+0xae/0x2d0[ 136.616319] ? do_user_addr_fault+0x379/0x670[ 136.616328] ? clear_bhb_loop+0x45/0xa0[ 136.616340] ? clear_bhb_loop+0x45/0xa0[ 136.616349] ? clear_bhb_loop+0x45/0xa0[ 136.616359] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 136.616369] RIP: 0033:0x7fd30ba7b047[ 136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44[ 136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c[ 136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047[ 136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003[ 136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c[ 136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340[ 136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38406 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath6kl: remove WARN on bad firmware inputIf the firmware gives bad input, that's nothing to do withthe driver's stack at this point etc., so the WARN_ON()doesn't add any value. Additionally, this is one of thetop syzbot reports now. Just print a message, and as anadded bonus, print the sizes too.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38410 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: Fix a fence leak in submit error pathIn error paths, we could unref the submit without callingdrm_sched_entity_push_job(), so msm_job_free() will never getcalled. Since drm_sched_job_cleanup() will NULL out thes_fence, we can use that to detect this case.Patchwork: https://patchwork.freedesktop.org/patch/653584/

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38412 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacksAfter retrieving WMI data blocks in sysfs callbacks, check for thevalidity of them before dereferencing their content.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38414 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850GCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crashon some specific platforms.Since this register is divergent for WCN7850 and QCN9274, move it toregister table to allow different definitions. Then correct the registeraddress 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38418 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: core: Release rproc->clean_table after rproc_attach() failsWhen rproc->state = RPROC_DETACHED is attached to remote processorthrough rproc_attach(), if rproc_handle_resources() returns failure,then the clean table should be released, otherwise the followingmemory leak will occur.unreferenced object 0xffff000086a99800 (size 1024):comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s)hex dump (first 32 bytes):00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............backtrace: [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230 [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260 [<0000000037818dae>] kmemdup+0x34/0x60 [<00000000610f7f57>] rproc_boot+0x35c/0x56c [<0000000065f8871a>] rproc_add+0x124/0x17c [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4 [<000000003bcaa37d>] platform_probe+0x68/0xd8 [<00000000771577f9>] really_probe+0x110/0x27c [<00000000531fea59>] __driver_probe_device+0x78/0x12c [<0000000080036a04>] driver_probe_device+0x3c/0x118 [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8 [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4 [<000000001a53b53e>] __device_attach+0xfc/0x18c [<00000000d1a2a32c>] device_initial_probe+0x14/0x20 [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4 unreferenced object 0xffff0000864c9690 (size 16):

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38419 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()When rproc->state = RPROC_DETACHED and rproc_attach() is usedto attach to the remote processor, if rproc_handle_resources()returns a failure, the resources allocated by imx_rproc_prepare()should be released, otherwise the following memory leak will occur.Since almost the same thing is done in imx_rproc_prepare() andrproc_resource_cleanup(), Function rproc_resource_cleanup() is ableto deal with empty lists so it is better to fix the "goto" statementsin rproc_attach(). replace the "unprepare_device" goto statement with"clean_up_resources" and get rid of the "unprepare_device" label.unreferenced object 0xffff0000861c5d00 (size 128):comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s)hex dump (first 32 bytes):00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............backtrace: [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0 [<00000000521c0345>] kmalloc_trace+0x40/0x158 [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8 [<000000002815755e>] imx_rproc_prepare+0xe0/0x180 [<0000000003f61b4e>] rproc_boot+0x2ec/0x528 [<00000000e7e994ac>] rproc_add+0x124/0x17c [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4 [<00000000efc298a1>] platform_probe+0x68/0xd8 [<00000000110be6fe>] really_probe+0x110/0x27c [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118 [<00000000a7874938>] __device_attach_driver+0xb8/0xf8 [<0000000065319e69>] bus_for_each_drv+0x84/0xe4 [<00000000db3eb243>] __device_attach+0xfc/0x18c [<0000000072e4e1a4>] device_initial_probe+0x14/0x20

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38420 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: carl9170: do not ping device which has failed to load firmwareSyzkaller reports [1, 2] crashes caused by an attempts to pingthe device which has failed to load firmware. Since such a devicedoesn't pass 'ieee80211_register_hw()', an internal workqueuemanaged by 'ieee80211_queue_work()' is not yet created and anattempt 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38424 Severity: Moderate CVSS3 score: 5.5

Description: 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 asynchronous external abort -- most likely due to trying to accessMMIO in bad ways.The crash further shows perf trying to do a user stack sample while inexit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the addressspace it is trying to access.It turns out that we stop perf after we tear down the userspace mm; areceipie for disaster, since perf likes to access userspace forvarious reasons.Flip this order by moving up where we stop perf in do_exit().Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USERto abort when the current task does not have an mm (exit_mm() makessure to set current->mm = NULL; before commencing with the actualteardown). Such that CPU wide events don't trip on this same problem.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38426 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Add basic validation for RAS headerIf RAS header read from EEPROM is corrupted, it could result in tryingto allocate huge memory for reading the records. Add some validation toheader fields.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38427 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:video: screen_info: Relocate framebuffers behind PCI bridgesApply PCI host-bridge window offsets to screen_info framebuffers. Fixesinvalid access to I/O memory.Resources behind a PCI host bridge can be relocated by a certain offsetin the kernel's CPU address range used for I/O. The framebuffer memoryrange stored in screen_info refers to the CPU addresses as seen duringboot (where the offset is 0). During boot up, firmware may assign adifferent memory offset to the PCI host bridge and thereby relocatingthe framebuffer address of the PCI graphics device as seen by the kernel.The information in screen_info must be updated as well.The helper pcibios_bus_to_resource() performs the relocation of thescreen_info's framebuffer resource (given in PCI bus addresses). Theresult matches the I/O-memory resource of the PCI graphics device (givenin CPU addresses). As before, we store away the information necessary tolater update the information in screen_info itself.Commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocatedEFI framebuffers") added the code for updating screen_info. It is basedon similar functionality that pre-existed in efifb. Efifb uses a pointerto the PCI resource, while the newer code does a memcpy of the region.Hence efifb sees any updates to the PCI resource and avoids the issue.v3:- Only use struct pci_bus_region for PCI bus addresses (Bjorn)- Clarify address semantics in commit messages and comments (Bjorn)v2:- Fixed tags (Takashi, Ivan)- Updated information on efifb

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38430 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: nfsd4_spo_must_allow() must check this is a v4 compound requestIf the request being processed is not a v4 compound request, thenexamining the cstate can have undefined results.This patch adds a check that the rpc procedure being executed(rq_procinfo) is the NFSPROC4_COMPOUND procedure.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38438 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak.sof_pdata->tplg_filename can have address allocated by kstrdup()and can be overwritten. Memory leak was detected with kmemleak:unreferenced object 0xffff88812391ff60 (size 16): comm "kworker/4:1", pid 161, jiffies 4294802931 hex dump (first 16 bytes): 73 6f 66 2d 68 64 61 2d 67 65 6e 65 72 69 63 00 sof-hda-generic. backtrace (crc 4bf1675c): __kmalloc_node_track_caller_noprof+0x49c/0x6b0 kstrdup+0x46/0xc0 hda_machine_select.cold+0x1de/0x12cf [snd_sof_intel_hda_generic] sof_init_environment+0x16f/0xb50 [snd_sof] sof_probe_continue+0x45/0x7c0 [snd_sof] sof_probe_work+0x1e/0x40 [snd_sof] process_one_work+0x894/0x14b0 worker_thread+0x5e5/0xfb0 kthread+0x39d/0x760 ret_from_fork+0x31/0x70 ret_from_fork_asm+0x1a/0x30

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38444 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:raid10: cleanup memleak at raid10_make_requestIf raid10_read_request or raid10_write_request registers a newrequest and the REQ_NOWAIT flag is set, the code does notfree the malloc from the mempool.unreferenced object 0xffff8884802c3200 (size 192): comm "fio", pid 9197, jiffies 4298078271 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A...... 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc c1a049a2): __kmalloc+0x2bb/0x450 mempool_alloc+0x11b/0x320 raid10_make_request+0x19e/0x650 [raid10] md_handle_request+0x3b3/0x9e0 __submit_bio+0x394/0x560 __submit_bio_noacct+0x145/0x530 submit_bio_noacct_nocheck+0x682/0x830 __blkdev_direct_IO_async+0x4dc/0x6b0 blkdev_read_iter+0x1e5/0x3b0 __io_read+0x230/0x1110 io_read+0x13/0x30 io_issue_sqe+0x134/0x1180 io_submit_sqes+0x48c/0xe90 __do_sys_io_uring_enter+0x574/0x8b0 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x76/0x7eV4: changing backing tree to see if CKI tests will pass.The patch code has not changed between any versions.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38445 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid1: Fix stack memory use after return in raid1_reshapeIn the raid1_reshape function, newpool isallocated on the stack and assigned to conf->r1bio_pool.This results in conf->r1bio_pool.wait.head pointingto a stack address.Accessing this address later can lead to a kernel panic.Example access path:raid1_reshape(){ // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool;}raid1_read_request() or raid1_write_request(){ alloc_r1bio() { mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } }}mempool_free(){ if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); }}Fix:reinit conf->r1bio_pool.wait after assigning newpool.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38451 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/md-bitmap: fix GPF in bitmap_get_stats()The commit message of commit 6ec1f0239485 ("md/md-bitmap: fix statscollection for external bitmaps") states: Remove the external bitmap check as the statistics should be available regardless of bitmap storage location. Return -EINVAL only for invalid bitmap with no storage (neither in superblock nor in external file).But, the code does not adhere to the above, as it does only check fora valid super-block for "internal" bitmaps. Hence, we observe:Oops: GPF, probably for non-canonical address 0x1cd66f1f40000028RIP: 0010:bitmap_get_stats+0x45/0xd0Call Trace: seq_read_iter+0x2b9/0x46a seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6d/0xf0 do_syscall_64+0x8c/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7eWe fix this by checking the existence of a super-block for both theinternal and external case.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38457 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Abort __tc_modify_qdisc if parent class does not existLion's patch [1] revealed an ancient bug in the qdisc API.Whenever a user creates/modifies a qdisc specifying as a parent anotherqdisc, the qdisc API will, during grafting, detect that the user isnot trying to attach to a class and reject. However grafting isperformed after qdisc_create (and thus the qdiscs' init callback) isexecuted. In qdiscs that eventually call qdisc_tree_reduce_backlogduring init or change (such as fq, hhf, choke, etc), an issuearises. For example, executing the following commands:sudo tc qdisc add dev lo root handle a: htb default 2sudo tc qdisc add dev lo parent a: handle beef fqQdiscs such as fq, hhf, choke, etc unconditionally invokeqdisc_tree_reduce_backlog() in their control path init() or change() whichthen causes a failure to find the child class; however, that does not stopthe unconditional invocation of the assumed child qdisc's qlen_notify witha null class. All these qdiscs make the assumption that class is non-null.The solution is ensure that qdisc_leaf() which looks up the parentclass, and is invoked prior to qdisc_create(), should return failure onnot finding the class.In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever theparentid doesn't correspond to a class, so that we can detect itearlier on and abort before qdisc_create is called.[1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38458 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix NULL pointer dereference in vcc_sendmsg()atmarpd_dev_ops does not implement the send method, which may cause crashas bellow.BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: Oops: 0010 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 ____sys_sendmsg+0x52d/0x830 net/socket.c:2566 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620 __sys_sendmmsg+0x227/0x430 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38459 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix infinite recursive call of clip_push().syzbot reported the splat below. [0]This happens if we call ioctl(ATMARP_MKIP) more than once.During the first call, clip_mkip() sets clip_push() to vcc->push(),and the second call copies it to clip_vcc->old_push().Later, when the socket is close()d, vcc_destroy_socket() passesNULL skb to clip_push(), which calls clip_vcc->old_push(),triggering the infinite recursion.Let's prevent the second ioctl(ATMARP_MKIP) by checkingvcc->user_back, which is allocated by the first call as clip_vcc.Note also that we use lock_sock() to prevent racy calls.[0]:BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000)Oops: stack guard page: 0000 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 <41> 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00RSP: 0018:ffffc9000d670000 EFLAGS: 00010246RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209eR10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578FS: 000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0Call Trace: clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200... clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 vcc_destroy_socket net/atm/common.c:183 [inline] vcc_release+0x157/0x460 net/atm/common.c:205 __sock_release net/socket.c:647 [inline] sock_close+0xc0/0x240 net/socket.c:1391 __fput+0x449/0xa70 fs/file_table.c:465 task_work_run+0x1d1/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:114 exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline] do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7ff31c98e929Code: 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 48RSP: 002b:00007fffb5aa1f78 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4RAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003RBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226fR10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608cR13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090 Modules linked in:

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38465 Severity: Moderate CVSS3 score: 5.5

Description: 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 conditionis always false as the two operands are of int.Then, a single socket can eat as many skb as possible until OOMhappens, and we can see multiple wraparounds of sk->sk_rmem_alloc.Let's fix it by using atomic_add_return() and comparing the twovariables 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38468 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtreehtb_lookup_leaf has a BUG_ON that can trigger with the following:tc qdisc del dev lo roottc qdisc add dev lo root handle 1: htb default 1tc class add dev lo parent 1: classid 1:1 htb rate 64bittc qdisc add dev lo parent 1:1 handle 2: netemtc qdisc add dev lo parent 2:1 handle 3: blackholeping -I lo -c1 -W0.001 127.0.0.1The root cause is the following:1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on the selected leaf qdisc2. netem_dequeue calls enqueue on the child qdisc3. blackhole_enqueue drops the packet and returns a value that is not just NET_XMIT_SUCCESS4. 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_erase5. As this is the only class in the selected hprio rbtree, __rb_change_child in __rb_erase_augmented sets the rb_root pointer to NULL6. 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_ONThe 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 returnsNULL.[1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38470 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtimeAssuming the "rx-vlan-filter" feature is enabled on a net device, the8021q module will automatically add or remove VLAN 0 when the net deviceis put administratively up or down, respectively. There are a couple ofproblems 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 bond1When the device is put administratively down the "rx-vlan-filter"feature is disabled, so the 8021q module will not remove VLAN 0 and thememory will be leaked [1].Another problem that can happen is that the kernel can automaticallydelete VLAN 0 when the device is put administratively down despite notadding it when the device was put administratively up since during thattime the "rx-vlan-filter" feature was disabled. null-ptr-unref orbug_on[2] will be triggered by unregister_vlan_dev() for refcountimbalance 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 vlan0Root 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=1step2: disable vlan filter feature and enable real_devstep3: change filter from 0 to 1vlan_device_event vlan_filter_push_vids ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0step4: real_dev downvlan_device_event vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0 vlan_info_rcu_free //free vlan0step5: delete vlan0unregister_vlan_dev BUG_ON(!vlan_info); //vlan_info is nullFix both problems by noting in the VLAN info whether VLAN 0 wasautomatically added upon NETDEV_UP and based on that decide whether itshould 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 PTICPU: 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/2014RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))RSP: 0018:ffff88810badf310 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9aRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017eFS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0Call Trace:

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38474 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: net: sierra: check for no status endpointThe driver checks for having three endpoints andhaving bulk in and out endpoints, but not thatthe third endpoint is interrupt input.Rectify the omission.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38484 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: backend: fix out-of-bound writeThe buffer is set to 80 character. If a caller write more characters,count is truncated to the max available space in "simple_write_to_buffer".But afterwards a string terminator is written to the buffer at offset countwithout boundary check. The zero termination is written OUT-OF-BOUND.Add a check that the given buffer is smaller then the buffer to prevent.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38487 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: aspeed: lpc-snoop: Don't disable channels that aren't enabledMitigate 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 ...

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38503 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix assertion when building free space treeWhen building the free space tree with the block group tree featureenabled, we can hit an assertion failure like this: BTRFS info (device loop0 state M): rebuilding free space tree assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1102! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 sp : ffff8000a4ce7600 x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8 x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001 x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160 x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0 x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00 x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0 x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e Call trace: populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P) btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337 btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074 btrfs_remount_rw fs/btrfs/super.c:1319 [inline] btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543 reconfigure_super+0x1d4/0x6f0 fs/super.c:1083 do_remount fs/namespace.c:3365 [inline] path_mount+0xb34/0xde0 fs/namespace.c:4200 do_mount fs/namespace.c:4221 [inline] __do_sys_mount fs/namespace.c:4432 [inline] __se_sys_mount fs/namespace.c:4409 [inline] __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409 __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 Code: f0047182 91178042 528089c3 9771d47b (d4210000) ---[ end trace 0000000000000000 ]---This happens because we are processing an empty block group, which hasno extents allocated from it, there are no items for this block group,including the block group item since block group items are stored in adedicated tree when using the block group tree feature. It also meansthis is the block group with the highest start offset, so there are nohigher keys in the extent root, hence btrfs_search_slot_for_read()returns 1 (no higher key found).Fix this by asserting 'ret' is 0 only if the block group tree featureis not enabled, in which case we should find a block group item forthe block group since it's stored in the extent root and block groupitem keys are greater than extent item keys (the value forBTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY andBTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively).In case 'ret' is 1, we just need to add a record to the free spacetree which spans the whole block group, and we can achieve this bymaking 'ret == 0' as the while loop's condition.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38509 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject VHT opmode for unsupported channel widthsVHT operating mode notifications are not defined for channel widthsbelow 20 MHz. In particular, 5 MHz and 10 MHz are not valid under theVHT specification and must be rejected.Without this check, malformed notifications using these widths mayreach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due toinvalid input. This issue was reported by syzbot.Reject these unsupported widths early in sta_link_apply_parameters()when opmode_notif is used. The accepted set includes 20, 40, 80, 160,and 80+80 MHz, which are valid for VHT. While 320 MHz is not definedfor VHT, it is allowed to avoid rejecting HE or EHT clients that maystill send a VHT opmode notification.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38514 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix oops due to non-existence of prealloc backlog structIf an AF_RXRPC service socket is opened and bound, but calls arepreallocated, then rxrpc_alloc_incoming_call() will oops because therxrpc_backlog struct doesn't get allocated until the first preallocation ismade.Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is nobacklog struct. This will cause the incoming call to be aborted.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38524 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix recv-recv race of completed callIf a call receives an event (such as incoming data), the call gets placedon the socket's queue and a thread in recvmsg can be awakened to go andprocess it. Once the thread has picked up the call off of the queue,further events will cause it to be requeued, and once the socket lock isdropped (recvmsg uses call->user_mutex to allow the socket to be used inparallel), a second thread can come in and its recvmsg can pop the call offthe socket queue again.In such a case, the first thread will be receiving stuff from the call andthe second thread will be blocked on call->user_mutex. The first threadcan, at this point, process both the event that it picked call for and theevent that the second thread picked the call for and may see the callterminate - in which case the call will be "released", decoupling the callfrom the user call ID assigned to it (RXRPC_USER_CALL_ID in the controlmessage).The first thread will return okay, but then the second thread will wake upholding the user_mutex and, if it sees that the call has been released bythe first thread, it will BUG thusly: kernel BUG at net/rxrpc/recvmsg.c:474!Fix this by just dequeuing the call and ignoring it if it is seen to bealready released. We can't tell userspace about it anyway as the user callID has become stale.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38526 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: add NULL check in eswitch lag checkThe function ice_lag_is_switchdev_running() is being called from outside ofthe LAG event handler code. This results in the lag->upper_netdev beingNULL sometimes. To avoid a NULL-pointer dereference, there needs to be acheck before it is dereferenced.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38553 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Restrict conditions for adding duplicating netems to qdisc treenetem_enqueue's duplication prevention logic breaks when a netemresides in a qdisc tree with other netems - this can lead to asoft lockup and OOM loop in netem_dequeue, as seen in [1].Ensure that a duplicating netem cannot exist in a tree with othernetems.Previous approaches suggested in discussions in chronological order:1) Track duplication status or ttl in the sk_buff struct. Consideredtoo specific a use case to extend such a struct, though this wouldbe a resilient fix and address other previous and potential futureDOS bugs like the one described in loopy fun [2].2) Restrict netem_enqueue recursion depth like in act_mirred with aper cpu variable. However, netem_dequeue can call enqueue on itschild, and the depth restriction could be bypassed if the child is anetem.3) Use the same approach as in 2, but add metadata in netem_skb_cbto handle the netem_dequeue case and track a packet's involvementin duplication. This is an overly complex approach, and Jamalnotes that the skb cb can be overwritten to circumvent thissafeguard.4) Prevent the addition of a netem to a qdisc tree if its ancestralpath contains a netem. However, filters and actions can cause apacket to change paths when re-enqueued to the root from netemduplication, leading us to the current solution: prevent aduplicating netem from inhabiting the same tree as other netems.[1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/[2] https://lwn.net/Articles/719297/

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38557 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: apple: validate feature-report field count to prevent NULL pointer dereferenceA malicious HID device with quirk APPLE_MAGIC_BACKLIGHT can trigger a NULLpointer dereference whilst the power feature-report is toggled and sent tothe device in apple_magic_backlight_report_set(). The power feature-reportis expected to have two data fields, but if the descriptor declares onefield then accessing field[1] and dereferencing it inapple_magic_backlight_report_set() becomes invalidsince field[1] will be NULL.An example of a minimal descriptor which can cause the crash is somethinglike the following where the report with ID 3 (power report) onlyreferences a single 1-byte field. When hid core parses the descriptor itwill encounter the final feature tag, allocate a hid_report (all membersof field[] will be zeroed out), create field structure and populate it,increasing the maxfield to 1. The subsequent field[1] access anddereference causes the crash. Usage Page (Vendor Defined 0xFF00) Usage (0x0F) Collection (Application) Report ID (1) Usage (0x01) Logical Minimum (0) Logical Maximum (255) Report Size (8) Report Count (1) Feature (Data,Var,Abs) Usage (0x02) Logical Maximum (32767) Report Size (16) Report Count (1) Feature (Data,Var,Abs) Report ID (3) Usage (0x03) Logical Minimum (0) Logical Maximum (1) Report Size (8) Report Count (1) Feature (Data,Var,Abs) End CollectionHere we see the KASAN splat when the kernel dereferences theNULL pointer and crashes: [ 15.164723] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN NOPTI [ 15.165691] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 15.165691] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0 #31 PREEMPT(voluntary) [ 15.165691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 15.165691] RIP: 0010:apple_magic_backlight_report_set+0xbf/0x210 [ 15.165691] Call Trace: [ 15.165691] [ 15.165691] apple_probe+0x571/0xa20 [ 15.165691] hid_device_probe+0x2e2/0x6f0 [ 15.165691] really_probe+0x1ca/0x5c0 [ 15.165691] __driver_probe_device+0x24f/0x310 [ 15.165691] driver_probe_device+0x4a/0xd0 [ 15.165691] __device_attach_driver+0x169/0x220 [ 15.165691] bus_for_each_drv+0x118/0x1b0 [ 15.165691] __device_attach+0x1d5/0x380 [ 15.165691] device_initial_probe+0x12/0x20 [ 15.165691] bus_probe_device+0x13d/0x180 [ 15.165691] device_add+0xd87/0x1510 [...]To fix this issue we should validate the number of fields that thebacklight and power reports have and if they do not have the requirednumber of fields then bail.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38559 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86/intel/pmt: fix a crashlog NULL pointer accessUsage of the intel_pmt_read() for binary sysfs, requires a pcidev. Thecurrent use of the endpoint value is only valid for telemetry endpointusage.Without the ep, the crashlog usage causes the following NULL pointerexception:BUG: kernel NULL pointer dereference, address: 0000000000000000Oops: Oops: 0000 [#1] SMP NOPTIRIP: 0010:intel_pmt_read+0x3b/0x70 [pmt_class]Code:Call Trace: ? sysfs_kf_bin_read+0xc0/0xe0 kernfs_fop_read_iter+0xac/0x1a0 vfs_read+0x26d/0x350 ksys_read+0x6b/0xe0 __x64_sys_read+0x1d/0x30 x64_sys_call+0x1bc8/0x1d70 do_syscall_64+0x6d/0x110Augment struct intel_pmt_entry with a pointer to the pcidev to avoidthe NULL pointer exception.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38569 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:benet: fix BUG when creating VFsbenet crashes as soon as SRIOV VFs are created: kernel BUG at mm/vmalloc.c:3457! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary) [...] RIP: 0010:vunmap+0x5f/0x70 [...] Call Trace: __iommu_dma_free+0xe8/0x1c0 be_cmd_set_mac_list+0x3fe/0x640 [be2net] be_cmd_set_mac+0xaf/0x110 [be2net] be_vf_eth_addr_config+0x19f/0x330 [be2net] be_vf_setup+0x4f7/0x990 [be2net] be_pci_sriov_configure+0x3a1/0x470 [be2net] sriov_numvfs_store+0x20b/0x380 kernfs_fop_write_iter+0x354/0x530 vfs_write+0x9b9/0xf60 ksys_write+0xf3/0x1d0 do_syscall_64+0x8c/0x3d0be_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh.Fix it by freeing only after the lock has been released.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38581 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp - Fix crash when rebind ccp device for ccp.koWhen CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebindingthe ccp device causes the following crash:$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind[ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098[ 204.978026] #PF: supervisor write access in kernel mode[ 204.979126] #PF: error_code(0x0002) - not-present page[ 204.980226] PGD 0 P4D 0[ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI...[ 204.997852] Call Trace:[ 204.999074] [ 205.000297] start_creating+0x9f/0x1c0[ 205.001533] debugfs_create_dir+0x1f/0x170[ 205.002769] ? srso_return_thunk+0x5/0x5f[ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp][ 205.005241] ccp5_init+0x8b2/0x960 [ccp][ 205.006469] ccp_dev_init+0xd4/0x150 [ccp][ 205.007709] sp_init+0x5f/0x80 [ccp][ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp][ 205.010165] ? srso_return_thunk+0x5/0x5f[ 205.011376] local_pci_probe+0x4f/0xb0[ 205.012584] pci_device_probe+0xdb/0x230[ 205.013810] really_probe+0xed/0x380[ 205.015024] __driver_probe_device+0x7e/0x160[ 205.016240] device_driver_attach+0x2f/0x60[ 205.017457] bind_store+0x7c/0xb0[ 205.018663] drv_attr_store+0x28/0x40[ 205.019868] sysfs_kf_write+0x5f/0x70[ 205.021065] kernfs_fop_write_iter+0x145/0x1d0[ 205.022267] vfs_write+0x308/0x440[ 205.023453] ksys_write+0x6d/0xe0[ 205.024616] __x64_sys_write+0x1e/0x30[ 205.025778] x64_sys_call+0x16ba/0x2150[ 205.026942] do_syscall_64+0x56/0x1e0[ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 205.029276] RIP: 0033:0x7fbc36f10104[ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5This patch sets ccp_debugfs_dir to NULL after destroying it inccp5_debugfs_destroy, allowing the directory dentry to berecreated when rebinding the ccp device.Tested on AMD Ryzen 7 1700X.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38583 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: xilinx: vcu: unregister pll_post only if registered correctlyIf registration of pll_post is failed, it will be set to NULL or ERR,unregistering same will fail with following call trace:Unable to handle kernel NULL pointer dereference at virtual address 008pc : clk_hw_unregister+0xc/0x20lr : clk_hw_unregister_fixed_factor+0x18/0x30sp : ffff800011923850...Call trace: clk_hw_unregister+0xc/0x20 clk_hw_unregister_fixed_factor+0x18/0x30 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu] xvcu_probe+0x2bc/0x53c [xlnx_vcu]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38586 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, arm64: Fix fp initialization for exception boundaryIn the ARM64 BPF JIT when prog->aux->exception_boundary is set for a BPFprogram, find_used_callee_regs() is not called because for a programacting as exception boundary, all callee saved registers are saved.find_used_callee_regs() sets `ctx->fp_used = true;` when it sees FPbeing used in any of the instructions.For programs acting as exception boundary, ctx->fp_used remains falseeven if frame pointer is used by the program and therefore, FP is notset-up for such programs in the prologue. This can cause the kernel tocrash due to a pagefault.Fix it by setting ctx->fp_used = true for exception boundary programs asfp is always saved in such programs.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38587 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix possible infinite loop in fib6_info_uses_dev()fib6_info_uses_dev() seems to rely on RCU without an explicitprotection.Like the prior fix in rt6_nlmsg_size(),we need to make sure fib6_del_route() or fib6_add_rt2node()have not removed the anchor from the list, or we risk an infinite loop.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38590 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Remove skb secpath if xfrm state is not foundHardware returns a unique identifier for a decrypted packet's xfrmstate, this state is looked up in an xarray. However, the state mighthave been freed by the time of this lookup.Currently, if the state is not found, only a counter is incremented.The secpath (sp) extension on the skb is not removed, resulting insp->len becoming 0.Subsequently, functions like __xfrm_policy_check() attempt to accessfields such as xfrm_input_state(skb)->xso.type (which dereferencessp->xvec[sp->len - 1]) without first validating sp->len. This leads toa crash when dereferencing an invalid state pointer.This patch prevents the crash by explicitly removing the secpathextension from the skb if the xfrm state is not found after hardwaredecryption. This ensures downstream functions do not operate on azero-length secpath. BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38597 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-portEach window of a vop2 is usable by a specific set of video ports, so whilebinding the vop2, we look through the list of available windows trying tofind one designated as primary-plane and usable by that specific port.The code later wants to use drm_crtc_init_with_planes with that foundprimary plane, but nothing has checked so far if a primary plane wasactually found.For whatever reason, the rk3576 vp2 does not have a usable primary window(if vp0 is also in use) which brought the issue to light and ended in anull-pointer dereference further down.As we expect a primary-plane to exist for a video-port, add a check atthe end of the window-iteration and fail probing if none was found.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38601 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: clear initialized flag for deinit-ed srng listsIn a number of cases we see kernel panics on resume dueto ath11k kernel page fault, which happens under thefollowing circumstances:1) First ath11k_hal_dump_srng_stats() call Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 22511ms before ath11k_pci 0000:01:00.0: group_id 1 14440788ms before [..] ath11k_pci 0000:01:00.0: failed to receive control response completion, polling.. ath11k_pci 0000:01:00.0: Service connect timeout ath11k_pci 0000:01:00.0: failed to connect to HTT: -110 ath11k_pci 0000:01:00.0: failed to start core: -110 ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM ath11k_pci 0000:01:00.0: already resetting count 2 ath11k_pci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110 ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -110 ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery [..]2) At this point reconfiguration fails (we have 2 resets) and ath11k_core_reconfigure_on_crash() calls ath11k_hal_srng_deinit() which destroys srng lists. However, it does not reset per-list ->initialized flag.3) Second ath11k_hal_dump_srng_stats() call sees stale ->initialized flag and attempts to dump srng stats: Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 66785ms before ath11k_pci 0000:01:00.0: group_id 1 14485062ms before ath11k_pci 0000:01:00.0: group_id 2 14485062ms before ath11k_pci 0000:01:00.0: group_id 3 14485062ms before ath11k_pci 0000:01:00.0: group_id 4 14780845ms before ath11k_pci 0000:01:00.0: group_id 5 14780845ms before ath11k_pci 0000:01:00.0: group_id 6 14485062ms before ath11k_pci 0000:01:00.0: group_id 7 66814ms before ath11k_pci 0000:01:00.0: group_id 8 68997ms before ath11k_pci 0000:01:00.0: group_id 9 67588ms before ath11k_pci 0000:01:00.0: group_id 10 69511ms before BUG: unable to handle page fault for address: ffffa007404eb010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k] Call Trace: ? __die_body+0xae/0xb0 ? page_fault_oops+0x381/0x3e0 ? exc_page_fault+0x69/0xa0 ? asm_exc_page_fault+0x22/0x30 ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)] ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)] worker_thread+0x389/0x930 kthread+0x149/0x170Clear per-list ->initialized flag in ath11k_hal_srng_deinit().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38602 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iwlwifi: Add missing check for alloc_ordered_workqueueAdd check for the return value of alloc_ordered_workqueue since it mayreturn NULL pointer.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38605 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Pass ab pointer directly to ath12k_dp_tx_get_encap_type()In ath12k_dp_tx_get_encap_type(), the arvif parameter is only used toretrieve the ab pointer. In vdev delete sequence the arvif->ar couldbecome NULL and that would trigger kernel panic.Since the caller ath12k_dp_tx() already has a valid ab pointer, pass itdirectly to avoid panic and unnecessary dereferencing.PC points to "ath12k_dp_tx+0x228/0x988 [ath12k]"LR points to "ath12k_dp_tx+0xc8/0x988 [ath12k]".The Backtrace obtained is as follows:ath12k_dp_tx+0x228/0x988 [ath12k]ath12k_mac_tx_check_max_limit+0x608/0x920 [ath12k]ieee80211_process_measurement_req+0x320/0x348 [mac80211]ieee80211_tx_dequeue+0x9ac/0x1518 [mac80211]ieee80211_tx_dequeue+0xb14/0x1518 [mac80211]ieee80211_tx_prepare_skb+0x224/0x254 [mac80211]ieee80211_xmit+0xec/0x100 [mac80211]__ieee80211_subif_start_xmit+0xc50/0xf40 [mac80211]ieee80211_subif_start_xmit+0x2e8/0x308 [mac80211]netdev_start_xmit+0x150/0x18cdev_hard_start_xmit+0x74/0xc0Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38609 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: Check governor before using governor->nameCommit 96ffcdf239de ("PM / devfreq: Remove redundant governor_name fromstruct devfreq") removes governor_name and uses governor->name to replaceit. But devfreq->governor may be NULL and directly usingdevfreq->governor->name may cause null pointer exception. Move the check ofgovernor to before using governor->name.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38610 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw()The get_pd_power_uw() function can crash with a NULL pointer dereferencewhen em_cpu_get() returns NULL. This occurs when a CPU becomes impossibleduring runtime, causing get_cpu_device() to return NULL, which propagatesthrough em_cpu_get() and leads to a crash when em_span_cpus() dereferencesthe NULL pointer.Add a NULL check after em_cpu_get() and return 0 if unavailable,matching the existing fallback behavior in __dtpm_cpu_setup().[ rjw: Drop an excess empty code line ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38612 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()In the error paths after fb_info structure is successfully allocated,the memory allocated in fb_deferred_io_init() for info->pagerefs is notfreed. Fix that by adding the cleanup function on the error path.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38614 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:eventpoll: Fix semi-unbounded recursionEnsure that epoll instances can never form a graph deeper thanEP_MAX_NESTS+1 links.Currently, ep_loop_check_proc() ensures that the graph is loop-free anddoes some recursion depth checks, but those recursion depth checks don'tlimit the depth of the resulting tree for two reasons: - They don't look upwards in the tree. - If there are multiple downwards paths of different lengths, only one of the paths is actually considered for the depth check since commit 28d82dc1c4ed ("epoll: limit paths").Essentially, the current recursion depth check in ep_loop_check_proc() justserves to prevent it from recursing too deeply while checking for loops.A more thorough check is done in reverse_path_check() after the new graphedge has already been created; this checks, among other things, that nopaths going upwards from any non-epoll file with a length of more than 5edges exist. However, this check does not apply to non-epoll files.As a result, it is possible to recurse to a depth of at least roughly 500,tested on v6.15. (I am unsure if deeper recursion is possible; and this mayhave changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversionproblem").)To fix it:1. In ep_loop_check_proc(), note the subtree depth of each visited node,and use subtree depths for the total depth calculation even when a subtreehas already been visited.2. Add ep_get_upwards_depth_proc() for similarly determining the maximumdepth of an upwards walk.3. In ep_loop_check(), use these values to limit the total path lengthbetween epoll nodes to EP_MAX_NESTS edges.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38621 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md: make rdev_addable usable for rcu modeOur testcase trigger panic:BUG: kernel NULL pointer dereference, address: 00000000000000e0...Oops: Oops: 0000 [#1] SMP NOPTICPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94PREEMPT(none)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014Workqueue: md_misc md_start_syncRIP: 0010:rdev_addable+0x4d/0xf0...Call Trace: md_start_sync+0x329/0x480 process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x14d/0x180 ret_from_fork_asm+0x1a/0x30 Modules linked in: raid10CR2: 00000000000000e0---[ end trace 0000000000000000 ]---RIP: 0010:rdev_addable+0x4d/0xf0md_spares_need_change in md_start_sync will call rdev_addable whichprotected by rcu_read_lock/rcu_read_unlock. This rcu context will helpprotect rdev won't be released, but rdev->mddev will be set to NULLbefore we call synchronize_rcu in md_kick_rdev_from_array. Fix this byusing READ_ONCE and check does rdev->mddev still alive.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38622 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: drop UFO packets in udp_rcv_segment()When sending a packet with virtio_net_hdr to tun device, if the gso_typein virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdrsize, below crash may happen. ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:4572! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skb_pull_rcsum+0x8e/0xa0 Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000 RSP: 0018:ffffc900001fba38 EFLAGS: 00000297 RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948 RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062 RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001 R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000 R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900 FS: 000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0 Call Trace: udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445 udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475 udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626 __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690 ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233 ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579 ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636 ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670 __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067 netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210 napi_complete_done+0x78/0x180 net/core/dev.c:6580 tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909 tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984 vfs_write+0x300/0x420 fs/read_write.c:593 ksys_write+0x60/0xd0 fs/read_write.c:686 do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63 To trigger gso segment in udp_queue_rcv_skb(), we should also set optionUDP_ENCAP_ESPINUDP to enable udp_sk(sk)->encap_rcv. When the encap_rcvhook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will tryto pull udphdr, but the skb size has been segmented to gso size, whichleads to this crash.Previous commit cf329aa42b66 ("udp: cope with UDP GRO packet misdirection")introduces segmentation in UDP receive path only for GRO, which was neverintended to be used for UFO, so drop UFO packets in udp_rcv_segment().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38624 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pnv_php: Clean up allocated IRQs on unplugWhen the root of a nested PCIe bridge configuration is unplugged, thepnv_php driver leaked the allocated IRQ resources for the child bridges'hotplug event notifications, resulting in a panic.Fix this by walking all child buses and deallocating all its IRQ resourcesbefore calling pci_hp_remove_devices().Also modify the lifetime of the workqueue at struct pnv_php_slot::wq sothat it is only destroyed in pnv_php_free_slot(), instead ofpnv_php_disable_irq(). This is required since pnv_php_disable_irq() willnow be called by workers triggered by hot unplug interrupts, so theworkqueue needs to stay allocated.The abridged kernel panic that occurs without this patch is as follows: WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2 Call Trace: msi_device_data_release+0x34/0x9c (unreliable) release_nodes+0x64/0x13c devres_release_all+0xc0/0x140 device_del+0x2d4/0x46c pci_destroy_dev+0x5c/0x194 pci_hp_remove_devices+0x90/0x128 pci_hp_remove_devices+0x44/0x128 pnv_php_disable_slot+0x54/0xd4 power_write_file+0xf8/0x18c pci_slot_attr_store+0x40/0x5c sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x3bc/0x50c ksys_write+0x84/0x140 system_call_exception+0x124/0x230 system_call_vectored_common+0x15c/0x2ec[bhelgaas: tidy comments]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38630 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-dereffb_add_videomode() can fail with -ENOMEM when its internal kmalloc() cannotallocate a struct fb_modelist. If that happens, the modelist stays empty butthe driver continues to register. Add a check for its return value to preventpoteintial null-ptr-deref, which is similar to the commit 17186f1f90d3 ("fbdev:Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var").

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38631 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: imx95-blk-ctl: Fix synchronous abortWhen enabling runtime PM for clock suppliers that also belong to a powerdomain, the following crash is thrown:error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMPWorkqueue: events_unbound deferred_probe_work_funcpstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : clk_mux_get_parent+0x60/0x90lr : clk_core_reparent_orphans_nolock+0x58/0xd8 Call trace: clk_mux_get_parent+0x60/0x90 clk_core_reparent_orphans_nolock+0x58/0xd8 of_clk_add_hw_provider.part.0+0x90/0x100 of_clk_add_hw_provider+0x1c/0x38 imx95_bc_probe+0x2e0/0x3f0 platform_probe+0x70/0xd8Enabling runtime PM without explicitly resuming the device causedthe power domain cut off after clk_register() is called. As a result,a crash happens when the clock hardware provider is added and attemptsto access the BLK_CTL register.Fix this by using devm_pm_runtime_enable() instead of pm_runtime_enable()and getting rid of the pm_runtime_disable() in the cleanup path.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38634 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:power: supply: cpcap-charger: Fix null check for power_supply_get_by_nameIn the cpcap_usb_detect() function, the power_supply_get_by_name()function may return `NULL` instead of an error pointer.To prevent potential null pointer dereferences, Added a null check.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38635 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: davinci: Add NULL check in davinci_lpsc_clk_register()devm_kasprintf() returns NULL when memory allocation fails. Currently,davinci_lpsc_clk_register() does not check for this case, which resultsin a NULL pointer dereference.Add NULL check after devm_kasprintf() to prevent this issue and ensuringno resources are left allocated.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38640 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Disable migration in nf_hook_run_bpf().syzbot reported that the netfilter bpf prog can be called withoutmigration disabled in xmit path.Then the assertion in __bpf_prog_run() fails, triggering the splatbelow. [0]Let's use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf().[0]:BUG: assuming non migratable context at ./include/linux/filter.h:703in_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session3 locks held by sshd-session/5829: #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline] #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395 #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470 #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 __cant_migrate kernel/sched/core.c:8860 [inline] __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834 __bpf_prog_run include/linux/filter.h:703 [inline] bpf_prog_run include/linux/filter.h:725 [inline] nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623 nf_hook+0x370/0x680 include/linux/netfilter.h:272 NF_HOOK_COND include/linux/netfilter.h:305 [inline] ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:459 [inline] ip_local_out net/ipv4/ip_output.c:129 [inline] __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527 __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479 tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline] tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838 __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021 tcp_push+0x225/0x700 net/ipv4/tcp.c:759 tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359 tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396 inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x4aa/0x5b0 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x6c7/0x1150 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:738 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/0x7fRIP: 0033:0x7fe7d365d407Code: 48 89 fa 4c 89 df e8 38 aa 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 ffRSP:

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38643 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()Callers of wdev_chandef() must hold the wiphy mutex.But the worker cfg80211_propagate_cac_done_wk() never takes the lock.Which triggers the warning below with the mesh_peer_connected_dfstest from hostapd and not (yet) released mac80211 code changes:WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165Modules linked in:CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cfWorkqueue: cfg80211 cfg80211_propagate_cac_done_wkStack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64irq event stamp: 614611hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xafhardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xafsoftirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38645 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Check device memory pointer before usageAdd a NULL check before accessing device memory to prevent a crash ifdev->dm allocation in mlx5_init_once() fails.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38656 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start()Preserve the error code if iwl_setup_deferred_work() fails. The currentcode returns ERR_PTR(0) (which is NULL) on this path. I believe themissing error code potentially leads to a use after free involvingdebugfs.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38660 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:[ceph] parse_longname(): strrchr() expects NUL-terminated string... and parse_longname() is not guaranteed that. That's the reasonwhy it uses kmemdup_nul() to build the argument for kstrtou64();the problem is, kstrtou64() is not the only thing that need it.Just get a NUL-terminated copy of the entire thing and be donewith that...

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38663 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: reject invalid file types when reading inodesTo prevent inodes with invalid file types from tripping through the vfsand causing malfunctions or assertion failures, add a missing sanity checkwhen reading an inode from a block device. If the file type is not valid,treat it as a filesystem error.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38665 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_modeAndrei Lalaev reported a NULL pointer deref when a CAN device isrestarted from Bus Off and the driver does not implement the structcan_priv::do_set_mode callback.There are 2 code path that call struct can_priv::do_set_mode:- directly by a manual restart from the user space, via can_changelink()- delayed automatic restart after bus off (deactivated by default)To prevent the NULL pointer deference, refuse a manual restart orconfigure the automatic restart delay in can_changelink() and reportthe error via extack to user space.As an additional safety measure let can_restart() return an error ifcan_priv::do_set_mode is not set instead of dereferencing itunchecked.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38668 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: fix NULL dereference on unbind due to stale coupling dataFailing to reset coupling_desc.n_coupled after freeing coupled_rdevs canlead to NULL pointer dereference when regulators are accessed post-unbind.This can happen during runtime PM or other regulator operations that relyon coupling metadata.For example, on ridesx4, unbinding the 'reg-dummy' platform device triggersa panic in regulator_lock_recursive() due to stale coupling state.Ensure n_coupled is set to 0 to prevent access to invalid pointers.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38670 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()`cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to changeto different stacks along with the Shadow Call Stack if it is enabled.Those two stack changes cannot be done atomically and both functionscan be interrupted by SErrors or Debug Exceptions which, though unlikely,is very much broken : if interrupted, we can end up with mismatched stacksand Shadow Call Stack leading to clobbered stacks.In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task,but x18 stills points to the old task's SCS. When the interrupt handlertries to save the task's SCS pointer, it will save the old taskSCS pointer (x18) into the new task struct (pointed to by SP_EL0),clobbering it.In `call_on_irq_stack()`, it can happen when switching from the task stackto the IRQ stack and when switching back. In both cases, we can beinterrupted when the SCS pointer points to the IRQ SCS, but SP points tothe task stack. The nested interrupt handler pushes its return addresseson the IRQ SCS. It then detects that SP points to the task stack,calls `call_on_irq_stack()` and clobbers the task SCS pointer withthe IRQ SCS pointer, which it will also use !This leads to tasks returning to addresses on the wrong SCS,or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACKor FPAC if enabled.This is possible on a default config, but unlikely.However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked andinstead the GIC is responsible for filtering what interrupts the CPUshould receive based on priority.Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPUeven in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very*frequently depending on the system configuration and workload, leadingto unpredictable kernel panics.Completely mask DAIF in `cpu_switch_to()` and restore it when returning.Do the same in `call_on_irq_stack()`, but restore and mask aroundthe branch.Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistencyof behaviour between all configurations.Introduce and use an assembly macro for saving and masking DAIF,as the existing one saves but only masks IF.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38671 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: qup: jump out of the loop in case of timeoutOriginal logic only sets the return value but doesn't jump out of theloop if the bus is kept active by a client. This is not expected. Amalicious or buggy i2c client can hang the kernel in this case andshould be avoided. This is observed during a long time test with aPCA953x GPIO extender.Fix it by changing the logic to not only sets the return value, but alsojumps out of the loop and return to the caller with -ETIMEDOUT.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38675 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: initialize state_ptrs earlier in xfrm_state_findIn case of preemption, xfrm_state_look_at will find a differentpcpu_id and look up states for that other CPU. If we matched a statefor CPU2 in the state_cache while the lookup started on CPU1, we willjump to "found", but the "best" state that we got will be ignored andwe will enter the "acquire" block. This block uses state_ptrs, whichisn't initialized at this point.Let's initialize state_ptrs just after taking rcu_read_lock. This willalso prevent a possible misuse in the future, if someone adjusts thisfunction.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38679 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: Fix OOB read due to missing payload bound checkCurrently, The event_seq_changed() handler processes a variable numberof properties sent by the firmware. The number of properties is indicatedby the firmware and used to iterate over the payload. However, thepayload size is not being validated against the actual message length.This can lead to out-of-bounds memory access if the firmware provides aproperty count that exceeds the data available in the payload. Such acondition can result in kernel crashes or potential information leaks ifmemory beyond the buffer is accessed.Fix this by properly validating the remaining size of the payload beforeeach property access and updating bounds accordingly as properties areparsed.This ensures that property parsing is safely bounded within the receivedmessage buffer and protects against malformed or malicious firmwarebehavior.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38680 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format()The buffer length check before calling uvc_parse_format() only ensuredthat the buffer has at least 3 bytes (buflen > 2), buf the functionaccesses buffer[3], requiring at least 4 bytes.This can lead to an out-of-bounds read if the buffer has exactly 3 bytes.Fix it by checking that the buffer has at least 4 bytes inuvc_parse_format().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38681 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd()Memory hot remove unmaps and tears down various kernel page table regionsas required. The ptdump code can race with concurrent modifications ofthe kernel page tables. When leaf entries are modified concurrently, thedump code may log stale or inconsistent information for a VA range, butthis is otherwise not harmful.But when intermediate levels of kernel page table are freed, the dump codewill continue to use memory that has been freed and potentiallyreallocated for another purpose. In such cases, the ptdump code maydereference bogus addresses, leading to a number of potential problems.To avoid the above mentioned race condition, platforms such as arm64,riscv and s390 take memory hotplug lock, while dumping kernel page tablevia the sysfs interface /sys/kernel/debug/kernel_page_tables.Similar race condition exists while checking for pages that might havebeen marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pageswhich in turn calls ptdump_check_wx(). Instead of solving this racecondition again, let's just move the memory hotplug lock inside genericptdump_check_wx() which will benefit both the scenarios.Drop get_online_mems() and put_online_mems() combination from all existingplatform ptdump code paths.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38683 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hv_netvsc: Fix panic during namespace deletion with VFThe existing code move the VF NIC to new namespace when NETDEV_REGISTER isreceived on netvsc NIC. During deletion of the namespace,default_device_exit_batch() >> default_device_exit_net() is called. Whennetvsc NIC is moved back and registered to the default namespace, itautomatically brings VF NIC back to the default namespace. This will causethe default_device_exit_net() >> for_each_netdev_safe loop unable to detectthe list end, and hit NULL ptr:[ 231.449420] mana 7870:00:00.0 enP30832s1: Moved VF to namespace with: eth0[ 231.449656] BUG: kernel NULL pointer dereference, address: 0000000000000010[ 231.450246] #PF: supervisor read access in kernel mode[ 231.450579] #PF: error_code(0x0000) - not-present page[ 231.450916] PGD 17b8a8067 P4D 0[ 231.451163] Oops: Oops: 0000 [#1] SMP NOPTI[ 231.451450] CPU: 82 UID: 0 PID: 1394 Comm: kworker/u768:1 Not tainted 6.16.0-rc4+ #3 VOLUNTARY[ 231.452042] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024[ 231.452692] Workqueue: netns cleanup_net[ 231.452947] RIP: 0010:default_device_exit_batch+0x16c/0x3f0[ 231.453326] Code: c0 0c f5 b3 e8 d5 db fe ff 48 85 c0 74 15 48 c7 c2 f8 fd ca b2 be 10 00 00 00 48 8d 7d c0 e8 7b 77 25 00 49 8b 86 28 01 00 00 <48> 8b 50 10 4c 8b 2a 4c 8d 62 f0 49 83 ed 10 4c 39 e0 0f 84 d6 00[ 231.454294] RSP: 0018:ff75fc7c9bf9fd00 EFLAGS: 00010246[ 231.454610] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 61c8864680b583eb[ 231.455094] RDX: ff1fa9f71462d800 RSI: ff75fc7c9bf9fd38 RDI: 0000000030766564[ 231.455686] RBP: ff75fc7c9bf9fd78 R08: 0000000000000000 R09: 0000000000000000[ 231.456126] R10: 0000000000000001 R11: 0000000000000004 R12: ff1fa9f70088e340[ 231.456621] R13: ff1fa9f70088e340 R14: ffffffffb3f50c20 R15: ff1fa9f7103e6340[ 231.457161] FS: 0000000000000000(0000) GS:ff1faa6783a08000(0000) knlGS:0000000000000000[ 231.457707] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 231.458031] CR2: 0000000000000010 CR3: 0000000179ab2006 CR4: 0000000000b73ef0[ 231.458434] Call Trace:[ 231.458600] [ 231.458777] ops_undo_list+0x100/0x220[ 231.459015] cleanup_net+0x1b8/0x300[ 231.459285] process_one_work+0x184/0x340To fix it, move the ns change to a workqueue, and take rtnl_lock to avoidchanging the netdev list when default_device_exit_net() is using it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38684 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: use old 'nbands' while purging unused classesShuang reported sch_ets test-case [1] crashing in ets_class_qlen_notify()after recent changes from Lion [2]. The problem is: in ets_qdisc_change()we purge unused DWRR queues; the value of 'q->nbands' is the new one, andthe cleanup should be done with the old one. The problem is here since myfirst attempts to fix ets_qdisc_change(), but it surfaced again after therecent qdisc len accounting fixes. Fix it purging idle DWRR queues beforeassigning a new value of 'q->nbands', so that all purge operations find aconsistent configuration: - old 'q->nbands' because it's needed by ets_class_find() - old 'q->nstrict' because it's needed by ets_class_is_strict() BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 62 UID: 0 PID: 39457 Comm: tc Kdump: loaded Not tainted 6.12.0-116.el10.x86_64 #1 PREEMPT(voluntary) Hardware name: Dell Inc. PowerEdge R640/06DKY5, BIOS 2.12.2 07/09/2021 RIP: 0010:__list_del_entry_valid_or_report+0x4/0x80 Code: ff 4c 39 c7 0f 84 39 19 8e ff b8 01 00 00 00 c3 cc cc cc cc 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <48> 8b 17 48 8b 4f 08 48 85 d2 0f 84 56 19 8e ff 48 85 c9 0f 84 ab RSP: 0018:ffffba186009f400 EFLAGS: 00010202 RAX: 00000000000000d6 RBX: 0000000000000000 RCX: 0000000000000004 RDX: ffff9f0fa29b69c0 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffffffc12c2400 R08: 0000000000000008 R09: 0000000000000004 R10: ffffffffffffffff R11: 0000000000000004 R12: 0000000000000000 R13: ffff9f0f8cfe0000 R14: 0000000000100005 R15: 0000000000000000 FS: 00007f2154f37480(0000) GS:ffff9f269c1c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001530be001 CR4: 00000000007726f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ets_class_qlen_notify+0x65/0x90 [sch_ets] qdisc_tree_reduce_backlog+0x74/0x110 ets_qdisc_change+0x630/0xa40 [sch_ets] __tc_modify_qdisc.constprop.0+0x216/0x7f0 tc_modify_qdisc+0x7c/0x120 rtnetlink_rcv_msg+0x145/0x3f0 netlink_rcv_skb+0x53/0x100 netlink_unicast+0x245/0x390 netlink_sendmsg+0x21b/0x470 ____sys_sendmsg+0x39d/0x3d0 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x7d/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f2155114084 Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d 25 f0 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff1fd7a988 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000560ec063e5e0 RCX: 00007f2155114084 RDX: 0000000000000000 RSI: 00007fff1fd7a9f0 RDI: 0000000000000003 RBP: 00007fff1fd7aa60 R08: 0000000000000010 R09: 000000000000003f R10: 0000560ee9b3a010 R11: 0000000000000202 R12: 00007fff1fd7aae0 R13: 000000006891ccde R14: 0000560ec063e5e0 R15: 00007fff1fd7aad0 [1] https://lore.kernel.org/netdev/e08c7f4a6882f260011909a868311c6e9b54f3e4.1639153474.git.dcaratti@redhat.com/ [2] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38686 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:userfaultfd: fix a crash in UFFDIO_MOVE when PMD is a migration entryWhen UFFDIO_MOVE encounters a migration PMD entry, it proceeds withobtaining a folio and accessing it even though the entry is swp_entry_t. Add the missing check and let split_huge_pmd() handle migration entries. While at it also remove unnecessary folio check.[surenb@google.com: remove extra folio check, per David]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38687 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: fix race between polling and detachingsyzbot reports a use-after-free in comedi in the below link, which isdue to comedi gladly removing the allocated async area even though pollrequests are still active on the wait_queue_head inside of it. This cancause a use-after-free when the poll entries are later triggered orremoved, as the memory for the wait_queue_head has been freed. We needto check there are no tasks queued on any of the subdevices' wait queuesbefore allowing the device to be detached by the `COMEDI_DEVCONFIG`ioctl.Tasks will read-lock `dev->attach_lock` before adding themselves to thesubdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctlhandler by write-locking `dev->attach_lock` before checking that all ofthe subdevices are safe to be deleted. This includes testing for anysleepers on the subdevices' wait queues. It remains locked until thedevice has been detached. This requires the `comedi_device_detach()`function to be refactored slightly, moving the bulk of it into newfunction `comedi_device_detach_locked()`.Note that the refactor of `comedi_device_detach()` results in`comedi_device_cancel_all()` now being called while `dev->attach_lock`is write-locked, which wasn't the case previously, but that does notmatter.Thanks to Jens Axboe for diagnosing the problem and co-developing thispatch.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38691 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pNFS: Fix uninited ptr deref in block/scsi layoutThe error occurs on the third attempt to encode extents. When functionext_tree_prepare_commit() reallocates a larger buffer to retry encodingextents, the "layoutupdate_pages" page array is initialized only after theretry loop. But ext_tree_free_commitdata() is called on every iterationand tries to put pages in the array, thus dereferencing uninitializedpointers.An additional problem is that there is no limit on the maximum possiblebuffer_size. When there are too many extents, the client may create alayoutcommit that is larger than the maximum possible RPC size acceptedby the server.During testing, we observed two typical scenarios. First, one memory pagefor extents is enough when we work with small files, append data to theend of the file, or preallocate extents before writing. But when we filla new large file without preallocating, the number of extents can be huge,and counting the number of written extents in ext_tree_encode_commit()does not help much. Since this number increases even more betweenunlocking and locking of ext_tree, the reallocated buffer may not belarge enough again and again.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38693 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: w7090p: fix null-ptr-deref in w7090p_tuner_write_serpar and w7090p_tuner_read_serparIn w7090p_tuner_write_serpar, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We addcheck on msg[0].len to prevent crash.Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38694 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: dib7090p: fix null-ptr-deref in dib7090p_rw_on_apb()In dib7090p_rw_on_apb, msg is controlled by user. When msg[0].buf is null andmsg[0].len is zero, former checks on msg[0].buf would be passed. If accessingmsg[0].buf[2] without sanity check, null pointer deref would happen. We addcheck on msg[0].len to prevent crash. Similar issue occurs when accessmsg[1].buf[0] and msg[1].buf[1].Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38704 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcu/nocb: Fix possible invalid rdp's->nocb_cb_kthread pointer accessIn the preparation stage of CPU online, if the correspondingthe rdp's->nocb_cb_kthread does not exist, will be created,there is a situation where the rdp's rcuop kthreads creation fails,and then de-offload this CPU's rdp, does not assign this CPU'srdp->nocb_cb_kthread pointer, but this rdp's->nocb_gp_rdp andrdp's->rdp_gp->nocb_gp_kthread is still valid.This will cause the subsequent re-offload operation of this offlineCPU, which will pass the conditional check and the kthread_unpark()will access invalid rdp's->nocb_cb_kthread pointer.This commit therefore use rdp's->nocb_gp_kthread instead ofrdp_gp's->nocb_gp_kthread for safety check.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38705 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix null pointer accessWriting a string without delimiters (' ', '\n', '\0') to the undergpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profilewill result in a null pointer dereference.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38717 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: kcm: Fix race condition in kcm_unattach()syzbot found a race condition when kcm_unattach(psock)and kcm_release(kcm) are executed at the same time.kcm_unattach() is missing a check of the flagkcm->tx_stopped before calling queue_work().If the kcm has a reserved psock, kcm_unattach() might get executedbetween cancel_work_sync() and unreserve_psock() in kcm_release(),requeuing kcm->tx_work right before kcm gets freed in kcm_done().Remove kcm->tx_stopped and replace it by the lesserror-prone disable_work_sync().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38718 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: linearize cloned gso packets in sctp_rcvA cloned head skb still shares these frag skbs in fraglist with theoriginal head skb. It's not safe to access these frag skbs.syzbot reported two use-of-uninitialized-memory bugs caused by this: BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122 __release_sock+0x1da/0x330 net/core/sock.c:3106 release_sock+0x6b/0x250 net/core/sock.c:3660 sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360 sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885 sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031 inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:718 [inline]and BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367 sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886 sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032 inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline]This patch fixes it by linearizing cloned gso packets in sctp_rcv().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38721 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: fix refcount leak on table dumpThere is a reference count leak in ctnetlink_dump_table(): if (res < 0) { nf_conntrack_get(&ct->ct_general); // HERE cb->args[1] = (unsigned long)ct; ...While its very unlikely, its possible that ct == last.If this happens, then the refcount of ct was already incremented.This 2nd increment is never undone.This prevents the conntrack object from being released, which in turnkeeps prevents cnet->count from dropping back to 0.This will then block the netns dismantle (or conntrack rmmod) asnf_conntrack_cleanup_net_list() will wait forever.This can be reproduced by running conntrack_resize.sh selftest in a loop.It takes ~20 minutes for me on a preemptible kernel on average beforeI see a runaway kworker spinning in nf_conntrack_cleanup_net_list.One fix would to change this to: if (res < 0) { if (ct != last) nf_conntrack_get(&ct->ct_general);But this reference counting isn't needed in the first place.We can just store a cookie value instead.A followup patch will do the same for ctnetlink_exp_dump_table,it looks to me as if this has the same problem and likectnetlink_dump_table, we only need a 'skip hint', not the actualobject so we can apply the same cookie strategy there as well.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38722 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:habanalabs: fix UAF in export_dmabuf()As soon as we'd inserted a file reference into descriptor table, anotherthread could close it. That's fine for the case when all we are doing isreturning that descriptor to userland (it's a race, but it's a userlandrace and there's nothing the kernel can do about it). However, if wefollow fd_install() with any kind of access to objects that would bedestroyed on close (be it the struct file itself or anything destroyedby its ->release()), we have a UAF.dma_buf_fd() is a combination of reserving a descriptor and fd_install().habanalabs export_dmabuf() calls it and then proceeds to access theobjects destroyed on close. In particular, it grabs an extra reference toanother struct file that will be dropped as part of ->release() for ours;that "will be" is actually "might have already been".Fix that by reserving descriptor before anything else and do fd_install()only when everything had been set up. As a side benefit, we no longerhave the failure exit with file already created, but reference tounderlying file (as well as ->dmabuf_export_cnt, etc.) not grabbed yet;unlike dma_buf_fd(), fd_install() can't fail.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38724 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()Lei Lu recently reported that nfsd4_setclientid_confirm() did not checkthe return value from get_client_locked(). a SETCLIENTID_CONFIRM couldrace with a confirmed client expiring and fail to get a reference. Thatcould later lead to a UAF.Fix this by getting a reference early in the case where there is anextant confirmed client. If that fails then treat it as if there were noconfirmed client found at all.In the case where the unconfirmed client is expiring, just fail andreturn the result from get_client_locked().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38725 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix_devices: add phy_mask for ax88772 mdio busWithout setting phy_mask for ax88772 mdio bus, current driver may createat most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f.DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phydevice will bind to net phy driver. This is creating issue during systemsuspend/resume since phy_polling_mode() in phy_state_machine() willdirectly deference member of phydev->drv for non-main phy devices. ThenNULL pointer dereference issue will occur. Due to only external phy orinternal phy is necessary, add phy_mask for ax88772 mdio bus to workarnoudthe issue.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38727 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: avoid infinite retry looping in netlink_unicast()netlink_attachskb() checks for the socket's read memory allocationconstraints. Firstly, it has: rmem < READ_ONCE(sk->sk_rcvbuf)to check if the just increased rmem value fits into the socket's receivebuffer. If not, it proceeds and tries to wait for the memory under: rmem + skb->truesize > READ_ONCE(sk->sk_rcvbuf)The checks don't cover the case when skb->truesize + sk->sk_rmem_alloc isequal to sk->sk_rcvbuf. Thus the function neither successfully acceptsthese conditions, nor manages to reschedule the task - and is called inretry loop for indefinite time which is caught as: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212 (t=26000 jiffies g=230833 q=259957) NMI backtrace for cpu 0 CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014 Call Trace: dump_stack lib/dump_stack.c:120 nmi_cpu_backtrace.cold lib/nmi_backtrace.c:105 nmi_trigger_cpumask_backtrace lib/nmi_backtrace.c:62 rcu_dump_cpu_stacks kernel/rcu/tree_stall.h:335 rcu_sched_clock_irq.cold kernel/rcu/tree.c:2590 update_process_times kernel/time/timer.c:1953 tick_sched_handle kernel/time/tick-sched.c:227 tick_sched_timer kernel/time/tick-sched.c:1399 __hrtimer_run_queues kernel/time/hrtimer.c:1652 hrtimer_interrupt kernel/time/hrtimer.c:1717 __sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1113 asm_call_irq_on_stack arch/x86/entry/entry_64.S:808 netlink_attachskb net/netlink/af_netlink.c:1234 netlink_unicast net/netlink/af_netlink.c:1349 kauditd_send_queue kernel/audit.c:776 kauditd_thread kernel/audit.c:897 kthread kernel/kthread.c:328 ret_from_fork arch/x86/entry/entry_64.S:304Restore the original behavior of the check which commit in Fixesaccidentally missed when restructuring the code.Found by Linux Verification Center (linuxtesting.org).

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38728 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb3: fix for slab out of bounds on mount to ksmbdWith KASAN enabled, it is possible to get a slab out of boundsduring mount to ksmbd due to missing check in parse_server_interfaces()(see below): BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827 CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 [cifs]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38729 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Validate UAC3 power domain descriptors, tooUAC3 power domain descriptors need to be verified with its variablebLength for avoiding the unexpected OOB accesses by maliciousfirmware, too.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38730 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/net: commit partial buffers on retryRing provided buffers are potentially only valid within the singleexecution context in which they were acquired. io_uring deals with thisand invalidates them on retry. But on the networking side, ifMSG_WAITALL is set, or if the socket is of the streaming type and toolittle was processed, then it will hang on to the buffer rather thanrecycle or commit it. This is problematic for two reasons:1) If someone unregisters the provided buffer ring before a later retry, then the req->buf_list will no longer be valid.2) If multiple sockers are using the same buffer group, then multiple receives can consume the same memory. This can cause data corruption in the application, as either receive could land in the same userspace buffer.Fix this by disallowing partial retries from pinning a provided bufferacross multiple executions, if ring provided buffers are used.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38733 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/mm: Do not map lowcore with identity mappingSince the identity mapping is pinned to address zero the lowcore is alwaysalso mapped to address zero, this happens regardless of the relocate_lowcorecommand line option. If the option is specified the lowcore is mappedtwice, instead of only once.This means that NULL pointer accesses will succeed instead of causing anexception (low address protection still applies, but covers only parts).To fix this never map the first two pages of physical memory with theidentity mapping.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38734 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix UAF on smcsk after smc_listen_out()BPF CI testing report a UAF issue: [ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0 [ 16.447134] #PF: supervisor read access in kernel mod e [ 16.447516] #PF: error_code(0x0000) - not-present pag e [ 16.447878] PGD 0 P4D 0 [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2 [ 16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL E [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4 [ 16.450201] Workqueue: smc_hs_wq smc_listen_wor k [ 16.450531] RIP: 0010:smc_listen_work+0xc02/0x159 0 [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6 [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0 [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0 [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5 [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0 [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0 [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0 [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3 [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0 [ 16.456459] PKRU: 5555555 4 [ 16.456654] Call Trace : [ 16.456832] [ 16.456989] ? __die+0x23/0x7 0 [ 16.457215] ? page_fault_oops+0x180/0x4c 0 [ 16.457508] ? __lock_acquire+0x3e6/0x249 0 [ 16.457801] ? exc_page_fault+0x68/0x20 0 [ 16.458080] ? asm_exc_page_fault+0x26/0x3 0 [ 16.458389] ? smc_listen_work+0xc02/0x159 0 [ 16.458689] ? smc_listen_work+0xc02/0x159 0 [ 16.458987] ? lock_is_held_type+0x8f/0x10 0 [ 16.459284] process_one_work+0x1ea/0x6d 0 [ 16.459570] worker_thread+0x1c3/0x38 0 [ 16.459839] ? __pfx_worker_thread+0x10/0x1 0 [ 16.460144] kthread+0xe0/0x11 0 [ 16.460372] ? __pfx_kthread+0x10/0x1 0 [ 16.460640] ret_from_fork+0x31/0x5 0 [ 16.460896] ? __pfx_kthread+0x10/0x1 0 [ 16.461166] ret_from_fork_asm+0x1a/0x3 0 [ 16.461453] [ 16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE) ] [ 16.462134] CR2: 000000000000003 0 [ 16.462380] ---[ end trace 0000000000000000 ]--- [ 16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590The direct cause of this issue is that after smc_listen_out_connected(),newclcsock->sk may be NULL since it will releases the smcsk. Therefore,if the application closes the socket immediately after accept,newclcsock->sk can be NULL. A possible execution order could be asfollows:smc_listen_work | userspace-----------------------------------------------------------------lock_sock(sk) |smc_listen_out_connected() || \- smc_listen_out || | \- release_sock | | |- sk->sk_data_ready() | | fd = accept(); | close(fd); | \- socket->sk = NULL;/* newclcsock->sk is NULL now */SMC_STAT_SERV_SUCC_INC(sock_net(newclcsock->sk))Since smc_listen_out_connected() will not fail, simply swapping the orderof the code can easily fix this issue.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38735 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: prevent ethtool ops after shutdownA crash can occur if an ethtool operation is invokedafter shutdown() is called.shutdown() is invoked during system shutdown to stop DMA operationswithout performing expensive deallocations. It is discouraged tounregister the netdev in this path, so the device may still be visibleto userspace and kernel helpers.In gve, shutdown() tears down most internal data structures. If anethtool operation is dispatched after shutdown(), it will dereferencefreed or NULL pointers, leading to a kernel panic. While gracefulshutdown normally quiesces userspace before invoking the rebootsyscall, forced shutdowns (as observed on GCP VMs) can still triggerthis path.Fix by calling netif_device_detach() in shutdown().This marks the device as detached so the ethtool ioctl handlerwill skip dispatching operations to the driver.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38736 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix_devices: Fix PHY address mask in MDIO bus initializationSyzbot reported shift-out-of-bounds exception on MDIO bus initialization.The PHY address should be masked to 5 bits (0-31). Without thismask, invalid PHY addresses could be used, potentially causing issueswith MDIO bus operations.Fix this by masking the PHY address with 0x1f (31 decimal) to ensureit stays within the valid range.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39673 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: fix race conditions in ppp_fill_forward_pathppp_fill_forward_path() has two race conditions:1. The ppp->channels list can change between list_empty() and list_first_entry(), as ppp_lock() is not held. If the only channel is deleted in ppp_disconnect_channel(), list_first_entry() may access an empty head or a freed entry, and trigger a panic.2. pch->chan can be NULL. When ppp_unregister_channel() is called, pch->chan is set to NULL before pch is removed from ppp->channels.Fix these by using a lockless RCU approach:- Use list_first_or_null_rcu() to safely test and access the first list entry.- Convert list modifications on ppp->channels to their RCU variants and add synchronize_net() after removal.- Check for a NULL pch->chan before dereferencing it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39675 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session()The function mod_hdcp_hdcp1_create_session() calls the functionget_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.Add a null pointer check for get_first_active_display() and returnMOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.This is similar to the commit c3e9826a2202("drm/amd/display: Add null pointer check for get_first_active_display()").(cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39676 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla4xxx: Prevent a potential error pointer dereferenceThe qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,but qla4xxx_ep_connect() returns error pointers. Propagating the errorpointers will lead to an Oops in the caller, so change the error pointersto NULL.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39677 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Fix backlog accounting in qdisc_dequeue_internalThis issue applies for the following qdiscs: hhf, fq, fq_codel, andfq_pie, and occurs in their change handlers when adjusting to the newlimit. The problem is the following in the values passed to thesubsequent qdisc_tree_reduce_backlog call given a tbf parent: When the tbf parent runs out of tokens, skbs of these qdiscs will be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued, which accounts for both qlen and backlog. However, in the case of qdisc_dequeue_internal, ONLY qlen is accounted for when pulling from gso_skb. This means that these qdiscs are missing a qdisc_qstats_backlog_dec when dropping packets to satisfy the new limit in their change handlers. One can observe this issue with the following (with tc patched to support a limit of 0): export TARGET=fq tc qdisc del dev lo root tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000 echo ''; echo 'add child'; tc -s -d qdisc show dev lo ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null echo ''; echo 'after ping'; tc -s -d qdisc show dev lo tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0 echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo tc qdisc replace dev lo handle 2: parent 1:1 sfq echo ''; echo 'post graft'; tc -s -d qdisc show dev lo The second to last show command shows 0 packets but a positive number (74) of backlog bytes. The problem becomes clearer in the last show command, where qdisc_purge_queue triggers qdisc_tree_reduce_backlog with the positive backlog and causes an underflow in the tbf parent's backlog (4096 Mb instead of 0).To fix this issue, the codepath for all clients of qdisc_dequeue_internalhas been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel.qdisc_dequeue_internal handles the backlog adjustments for all cases thatdo not directly use the dequeue handler.The old fq_codel_change limit adjustment loop accumulated the arguments tothe subsequent qdisc_tree_reduce_backlog call through the cstats field.However, this is confusing and error prone as fq_codel_dequeue could alsopotentially mutate this field (which qdisc_dequeue_internal calls in thenon gso_skb case), so we have unified the code here with other qdiscs.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39678 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86/amd/hsmp: Ensure sock->metric_tbl_addr is non-NULLIf metric table address is not allocated, accessing metrics_bin willresult in a NULL pointer dereference, so add a check.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39679 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().When the nvif_vmm_type is invalid, we will return error directlywithout freeing the args in nvif_vmm_ctor(), which leading a memoryleak. Fix it by setting the ret -EINVAL and goto done.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39681 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helperSince 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")resctrl_cpu_detect() has been moved from common CPU initialization code tothe vendor-specific BSP init helper, while Hygon didn't put that call in theircode.This triggers a division by zero fault during early booting stage on ourmachines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() triesto calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale.Add the missing resctrl_cpu_detect() in the Hygon BSP init helper. [ bp: Massage commit message. ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39683 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Limit access to parser->buffer when trace_get_user failedWhen the length of the string written to set_ftrace_filter exceedsFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0Read of size 1 at addr ffff0000d00bd5ba by task ash/165CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirtyHardware name: linux,dummy-virt (DT)Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0The reason is that trace_get_user will fail when processing a stringlonger than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0.Then an OOB access will be triggered in ftrace_regex_release->ftrace_process_regex->strsep->strpbrk. We can solve this problem bylimiting access to parser->buffer when trace_get_user failed.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39684 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()syzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`. A kernelbuffer is allocated to hold `insn->n` samples (each of which is an`unsigned int`). For some instruction types, `insn->n` samples arecopied back to user-space, unless an error code is being returned. Theproblem is that not all the instruction handlers that need to returndata to userspace fill in the whole `insn->n` samples, so that there isan information leak. There is a similar syzbot report for`do_insnlist_ioctl()`, although it does not have a reproducer for it atthe time of writing.One culprit is `insn_rw_emulate_bits()` which is used as the handler for`INSN_READ` or `INSN_WRITE` instructions for subdevices that do not havea specific handler for that instruction, but do have an `INSN_BITS`handler. For `INSN_READ` it only fills in at most 1 sample, so if`insn->n` is greater than 1, the remaining `insn->n - 1` samples copiedto userspace will be uninitialized kernel data.Another culprit is `vm80xx_ai_insn_read()` in the "vm80xx" driver. Itnever returns an error, even if it fails to fill the buffer.Fix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making surethat uninitialized parts of the allocated buffer are zeroed beforehandling each instruction.Thanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`. That fixreplaced the call to `kmalloc_array()` with `kcalloc()`, but it is notalways necessary to clear the whole buffer.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39685 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: pcl726: Prevent invalid irq numberThe reproducer passed in an irq number(0x80008000) that was too large,which triggered the oob.Added an interrupt number check to prevent users from passing in an irqnumber that was too large.If `it->options[1]` is 31, then `1 << it->options[1]` is still invalidbecause it shifts a 1-bit into the sign bit (which is UB in C).Possible solutions include reducing the upper bound on the`it->options[1]` value to 30 or lower, or using `1U << it->options[1]`.The old code would just not attempt to request the IRQ if the`options[1]` value were invalid. And it would still configure thedevice without interrupts even if the call to `request_irq` returned anerror. So it would be better to combine this test with the test below.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39686 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Make insn_rw_emulate_bits() do insn->n samplesThe `insn_rw_emulate_bits()` function is used as a default handler for`INSN_READ` instructions for subdevices that have a handler for`INSN_BITS` but not for `INSN_READ`. Similarly, it is used as a defaulthandler for `INSN_WRITE` instructions for subdevices that have a handlerfor `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the`INSN_READ` or `INSN_WRITE` instruction handling with a constructed`INSN_BITS` instruction. However, `INSN_READ` and `INSN_WRITE`instructions are supposed to be able read or write multiple samples,indicated by the `insn->n` value, but `insn_rw_emulate_bits()` currentlyonly handles a single sample. For `INSN_READ`, the comedi core willcopy `insn->n` samples back to user-space. (That triggered KASANkernel-infoleak errors when `insn->n` was greater than 1, but that isbeing fixed more generally elsewhere in the comedi core.)Make `insn_rw_emulate_bits()` either handle `insn->n` samples, or returnan error, to conform to the general expectation for `INSN_READ` and`INSN_WRITE` handlers.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39687 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: as73211: Ensure buffer holes are zeroedGiven that the buffer is copied to a kfifo that ultimately user spacecan read, ensure we zero it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39689 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Also allocate and copy hash for reading of filter filesCurrently the reader of set_ftrace_filter and set_ftrace_notrace just addsthe pointer to the global tracer hash to its iterator. Unlike the writerthat allocates a copy of the hash, the reader keeps the pointer to thefilter hashes. This is problematic because this pointer is static acrossfunction calls that release the locks that can update the global tracerhashes. This can cause UAF and similar bugs.Allocate and copy the hash for reading the filter files like it is donefor the writers. This not only fixes UAF bugs, but also makes the code abit simpler as it doesn't have to differentiate when to free theiterator's hash between writers and readers.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39693 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Avoid a NULL pointer dereference[WHY]Although unlikely drm_atomic_get_new_connector_state() ordrm_atomic_get_old_connector_state() can return NULL.[HOW]Check returns before dereference.(cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39694 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Fix SCCB present checkTracing code called by the SCLP interrupt handler contains early exitsif the SCCB address associated with an interrupt is NULL. This check isperformed after physical to virtual address translation.If the kernel identity mapping does not start at address zero, theresulting virtual address is never zero, so that the NULL checks won'twork. Subsequently this may result in incorrect accesses to the firstpage of the identity mapping.Fix this by introducing a function that handles the NULL case beforeaddress translation.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39695 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Flush delayed SKBs while releasing RXE resourcesWhen skb packets are sent out, these skb packets still depends onthe rxe resources, for example, QP, sk, when these packets aredestroyed.If these rxe resources are released when the skb packets are destroyed,the call traces will appear.To avoid skb packets hang too long time in some network devices,a timestamp is added when these skb packets are created. If theseskb packets hang too long time in network devices, these networkdevices can free these skb packets to release rxe resources.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39697 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix a race when updating an existing writeAfter nfs_lock_and_join_requests() tests for whether the request isstill attached to the mapping, nothing prevents a call tonfs_inode_remove_request() from succeeding until we actually lock thepage group.The reason is that whoever called nfs_inode_remove_request() doesn'tnecessarily have a lock on the page group head.So in order to avoid races, let's take the page group lock earlier innfs_lock_and_join_requests(), and hold it across the removal of therequest in nfs_inode_remove_request().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39700 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/ops-common: ignore migration request to invalid nodesdamon_migrate_pages() tries migration even if the target node is invalid. If users mistakenly make such invalid requests viaDAMOS_MIGRATE_{HOT,COLD} action, the below kernel BUG can happen. [ 7831.883495] BUG: unable to handle page fault for address: 0000000000001f48 [ 7831.884160] #PF: supervisor read access in kernel mode [ 7831.884681] #PF: error_code(0x0000) - not-present page [ 7831.885203] PGD 0 P4D 0 [ 7831.885468] Oops: Oops: 0000 [#1] SMP PTI [ 7831.885852] CPU: 31 UID: 0 PID: 94202 Comm: kdamond.0 Not tainted 6.16.0-rc5-mm-new-damon+ #93 PREEMPT(voluntary) [ 7831.886913] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.el9 04/01/2014 [ 7831.887777] RIP: 0010:__alloc_frozen_pages_noprof (include/linux/mmzone.h:1724 include/linux/mmzone.h:1750 mm/page_alloc.c:4936 mm/page_alloc.c:5137) [...] [ 7831.895953] Call Trace: [ 7831.896195] [ 7831.896397] __folio_alloc_noprof (mm/page_alloc.c:5183 mm/page_alloc.c:5192) [ 7831.896787] migrate_pages_batch (mm/migrate.c:1189 mm/migrate.c:1851) [ 7831.897228] ? __pfx_alloc_migration_target (mm/migrate.c:2137) [ 7831.897735] migrate_pages (mm/migrate.c:2078) [ 7831.898141] ? __pfx_alloc_migration_target (mm/migrate.c:2137) [ 7831.898664] damon_migrate_folio_list (mm/damon/ops-common.c:321 mm/damon/ops-common.c:354) [ 7831.899140] damon_migrate_pages (mm/damon/ops-common.c:405) [...]Add a target node validity check in damon_migrate_pages(). The validitycheck is stolen from that of do_pages_move(), which is being used for themove_pages() system call.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39701 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: pfr_update: Fix the driver update version checkThe security-version-number check should be used ratherthan the runtime version check for driver updates.Otherwise, the firmware update would fail when the update binary hada lower runtime version number than the current one.[ rjw: Changelog edits ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39702 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39703 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net, hsr: reject HSR frame if skb can't hold tagReceiving HSR frame with insufficient space to hold HSR tag in the skbcan result in a crash (kernel BUG):[ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1[ 45.392559] ------------[ cut here ]------------[ 45.392912] kernel BUG at net/core/skbuff.c:211![ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI[ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef)[ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0[ 45.402911] Call Trace:[ 45.403105] [ 45.404470] skb_push+0xcd/0xf0[ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0[ 45.406513] br_forward_finish+0x128/0x260[ 45.408483] __br_forward+0x42d/0x590[ 45.409464] maybe_deliver+0x2eb/0x420[ 45.409763] br_flood+0x174/0x4a0[ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0[ 45.411618] br_handle_frame+0xac3/0x1230[ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0[ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0[ 45.424478] __netif_receive_skb+0x22/0x170[ 45.424806] process_backlog+0x242/0x6d0[ 45.425116] __napi_poll+0xbb/0x630[ 45.425394] net_rx_action+0x4d1/0xcc0[ 45.427613] handle_softirqs+0x1a4/0x580[ 45.427926] do_softirq+0x74/0x90[ 45.428196] This issue was found by syzkaller.The panic happens in br_dev_queue_push_xmit() once it receives acorrupted skb with ETH header already pushed in linear data. When itattempts the skb_push() call, there's not enough headroom andskb_push() panics.The corrupted skb is put on the queue by HSR layer, which makes asequence of unintended transformations when it receives a specificcorrupted HSR frame (with incomplete TAG).Fix it by dropping and consuming frames that are not long enough tocontain both ethernet and hsr headers.Alternative fix would be to check for enough headroom before skb_push()in br_dev_queue_push_xmit().In the reproducer, this is injected via AF_PACKET, but I don't easilysee why it couldn't be sent over the wire from adjacent network.Further Details:In the reproducer, the following network interface chain is set up: ────────────────┐ ────────────────┐| veth0_to_hsr ├───┤ hsr_slave0 ┼───┐ ────────────────┘ ────────────────┘ | | ──────┐ ├─┤ hsr0 ├───┐ | ──────┘ | ────────────────┐ ────────────────┐ | | ────────┐| veth1_to_hsr ┼───┤ hsr_slave1 ├───┘ ┤ | ────────────────┘ ────────────────┘ ┼ bridge | || | | ────────┘ | ───────┐ | | ... ├──────┘ ───────┘To trigger the events leading up to crash, reproducer sends a corruptedHSR fr---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39704 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: KVM: Fix stack protector issue in send_ipi_data()Function kvm_io_bus_read() is called in function send_ipi_data(), buffersize of parameter *val should be at least 8 bytes. Since some emulationfunctions like loongarch_ipi_readl() and kvm_eiointc_read() will writethe buffer *val with 8 bytes signed extension regardless parameter len.Otherwise there will be buffer overflow issue when CONFIG_STACKPROTECTORis enabled. The bug report is shown as follows:Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: send_ipi_data+0x194/0x1a0 [kvm]CPU: 11 UID: 107 PID: 2692 Comm: CPU 0/KVM Not tainted 6.17.0-rc1+ #102 PREEMPT(full)Stack : 9000000005901568 0000000000000000 9000000003af371c 900000013c68c000 900000013c68f850 900000013c68f858 0000000000000000 900000013c68f998 900000013c68f990 900000013c68f990 900000013c68f6c0 fffffffffffdb058 fffffffffffdb0e0 900000013c68f858 911e1d4d39cf0ec2 9000000105657a00 0000000000000001 fffffffffffffffe 0000000000000578 282049464555206e 6f73676e6f6f4c20 0000000000000001 00000000086b4000 0000000000000000 0000000000000000 0000000000000000 9000000005709968 90000000058f9000 900000013c68fa68 900000013c68fab4 90000000029279f0 900000010153f940 900000010001f360 0000000000000000 9000000003af3734 000000004390000c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ...Call Trace:[<9000000003af3734>] show_stack+0x5c/0x180[<9000000003aed168>] dump_stack_lvl+0x6c/0x9c[<9000000003ad0ab0>] vpanic+0x108/0x2c4[<9000000003ad0ca8>] panic+0x3c/0x40[<9000000004eb0a1c>] __stack_chk_fail+0x14/0x18[] send_ipi_data+0x190/0x1a0 [kvm][] __kvm_io_bus_write+0xa4/0xe8 [kvm][] kvm_io_bus_write+0x54/0x90 [kvm][] kvm_emu_iocsr+0x180/0x310 [kvm][] kvm_handle_gspr+0x280/0x478 [kvm][] kvm_handle_exit+0xc0/0x130 [kvm]

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39705 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: fix a Null pointer dereference vulnerability[Why]A null pointer dereference vulnerability exists in the AMD display driver's(DC module) cleanup function dc_destruct().When display control context (dc->ctx) construction fails(due to memory allocation failure), this pointer remains NULL.During subsequent error handling when dc_destruct() is called,there's no NULL check before dereferencing the perf_trace member(dc->ctx->perf_trace), causing a kernel null pointer dereference crash.[How]Check if dc->ctx is non-NULL before dereferencing.(Updated commit text and removed unnecessary error message)(cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39709 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: protect against spurious interrupts during probeMake sure the interrupt handler is initialized before the interrupt isregistered.If the IRQ is registered before hfi_create(), it's possible that aninterrupt fires before the handler setup is complete, leading to a NULLdereference.This error condition has been observed during system boot on Rb3Gen2.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39710 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: Add a check for packet size after reading from shared memoryAdd a check to ensure that the packet size does not exceed the number ofavailable words after reading the packet header from shared memory. Thisensures that the size provided by the firmware is safe to process andprevent potential out-of-bounds memory access.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39711 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() callsBoth the ACE and CSI driver are missing a mei_cldev_disable() call intheir remove() function.This causes the mei_cl client to stay part of the mei_device->file_listlist even though its memory is freed by mei_cl_bus_dev_release() callingkfree(cldev->cl).This leads to a use-after-free when mei_vsc_remove() runs mei_stop()which first removes all mei bus devices calling mei_ace_remove() andmei_csi_remove() followed by mei_cl_bus_dev_release() and then callsmei_cl_all_disconnect() which walks over mei_device->file_list dereferecingthe just freed cldev->cl.And mei_vsc_remove() it self is run at shutdown because of theplatform_device_unregister(tp->pdev) in vsc_tp_shutdown()When building a kernel with KASAN this leads to the following KASAN report:[ 106.634504] ==================================================================[ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei[ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1[ 106.634729][ 106.634767] Tainted: [E]=UNSIGNED_MODULE[ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025[ 106.634773] Call Trace:[ 106.634777] ...[ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)[ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei[ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei[ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei...[ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei[ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc[ 106.635066] platform_remove (drivers/base/platform.c:1424)Add the missing mei_cldev_disable() calls so that the mei_cl gets removedfrom mei_device->file_list before it is freed to fix this.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39712 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: mt9m114: Fix deadlock in get_frame_interval/set_frame_intervalGetting / Setting the frame interval using the V4L2 subdev pad opsget_frame_interval/set_frame_interval causes a deadlock, as thesubdev state is locked in the [1] but also in the driver itself.In [2] it's described that the caller is responsible to acquire andrelease the lock in this case. Therefore, acquiring the lock in thedriver is wrong.Remove the lock acquisitions/releases from mt9m114_ifp_get_frame_interval()and mt9m114_ifp_set_frame_interval().[1] drivers/media/v4l2-core/v4l2-subdev.c - line 1129[2] Documentation/driver-api/media/v4l2-subdev.rst

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39713 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()In the interrupt handler rain_interrupt(), the buffer full check onrain->buf_len is performed before acquiring rain->buf_lock. Thiscreates a Time-of-Check to Time-of-Use (TOCTOU) race condition, asrain->buf_len is concurrently accessed and modified in the workhandler rain_irq_work_handler() under the same lock.Multiple interrupt invocations can race, with each reading buf_lenbefore it becomes full and then proceeding. This can lead to bothinterrupts attempting to write to the buffer, incrementing buf_lenbeyond its capacity (DATA_SIZE) and causing a buffer overflow.Fix this bug by moving the spin_lock() to before the buffer fullcheck. This ensures that the check and the subsequent buffer modificationare performed atomically, preventing the race condition. An correspondingspin_unlock() is added to the overflow path to correctly release thelock.This possible bug was found by an experimental static analysis tooldeveloped by our team.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39714 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: usbtv: Lock resolution while streamingWhen an program is streaming (ffplay) and another program (qv4l2)changes the TV standard from NTSC to PAL, the kernel crashes due to tryingto copy to unmapped memory.Changing from NTSC to PAL increases the resolution in the usbtv struct,but the video plane buffer isn't adjusted, so it overflows.[hverkuil: call vb2_is_busy instead of vb2_is_streaming]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39718 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: Validate length in packet header before skb_put()When receiving a vsock packet in the guest, only the virtqueue buffersize is validated prior to virtio_vsock_skb_rx_put(). Unfortunately,virtio_vsock_skb_rx_put() uses the length from the packet header as thelength argument to skb_put(), potentially resulting in SKB overflow ifthe host has gone wonky.Validate the length as advertised by the packet header before callingvirtio_vsock_skb_rx_put().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39719 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: bno055: fix OOB access of hw_xlate arrayFix a potential out-of-bounds array access of the hw_xlate array inbno055.c.In bno055_get_regmask(), hw_xlate was iterated over the length of thevals array instead of the length of the hw_xlate array. In the case ofbno055_gyr_scale, the vals array is larger than the hw_xlate array,so this could result in an out-of-bounds access. In practice, thisshouldn't happen though because a match should always be found whichbreaks out of the for loop before it iterates beyond the end of thehw_xlate array.By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can besure we are iterating over the correct length.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39721 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - flush misc workqueue during device shutdownRepeated loading and unloading of a device specific QAT driver, forexample qat_4xxx, in a tight loop can lead to a crash due to ause-after-free scenario. This occurs when a power management (PM)interrupt triggers just before the device-specific driver (e.g.,qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remainsloaded.Since the driver uses a shared workqueue (`qat_misc_wq`) across alldevices and owned by intel_qat.ko, a deferred routine from thedevice-specific driver may still be pending in the queue. If thisroutine executes after the driver is unloaded, it can dereference freedmemory, resulting in a page fault and kernel crash like the following: BUG: unable to handle page fault for address: ffa000002e50a01c #PF: supervisor read access in kernel mode RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat] Call Trace: pm_bh_handler+0x1d2/0x250 [intel_qat] process_one_work+0x171/0x340 worker_thread+0x277/0x3a0 kthread+0xf0/0x120 ret_from_fork+0x2d/0x50To prevent this, flush the misc workqueue during device shutdown toensure that all pending work items are completed before the driver isunloaded.Note: This approach may slightly increase shutdown latency if theworkqueue contains jobs from other devices, but it ensures correctnessand stability.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39722 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: caam - Prevent crash on suspend with iMX8QM / iMX8ULPSince the CAAM on these SoCs is managed by another ARM core, called theSECO (Security Controller) on iMX8QM and Secure Enclave on iMX8ULP, whichalso reserves access to register page 0 suspend operations cannot touchthis page.This is similar to when running OPTEE, where OPTEE will reserve page 0.Track this situation using a new state variable no_page0, reflecting ifpage 0 is reserved elsewhere, either by other management cores in SoC orby OPTEE.Replace the optee_en check in suspend/resume with the new check.optee_en cannot go away as it's needed elsewhere to gate OPTEE specificsituations.Fixes the following splat at suspend: Internal error: synchronous external abort: 0000000096000010 [#1] SMP Hardware name: Freescale i.MX8QXP ACU6C (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : readl+0x0/0x18 lr : rd_reg32+0x18/0x3c sp : ffffffc08192ba20 x29: ffffffc08192ba20 x28: ffffff8025190000 x27: 0000000000000000 x26: ffffffc0808ae808 x25: ffffffc080922338 x24: ffffff8020e89090 x23: 0000000000000000 x22: ffffffc080922000 x21: ffffff8020e89010 x20: ffffffc080387ef8 x19: ffffff8020e89010 x18: 000000005d8000d5 x17: 0000000030f35963 x16: 000000008f785f3f x15: 000000003b8ef57c x14: 00000000c418aef8 x13: 00000000f5fea526 x12: 0000000000000001 x11: 0000000000000002 x10: 0000000000000001 x9 : 0000000000000000 x8 : ffffff8025190870 x7 : ffffff8021726880 x6 : 0000000000000002 x5 : ffffff80217268f0 x4 : ffffff8021726880 x3 : ffffffc081200000 x2 : 0000000000000001 x1 : ffffff8020e89010 x0 : ffffffc081200004 Call trace: readl+0x0/0x18 caam_ctrl_suspend+0x30/0xdc dpm_run_callback.constprop.0+0x24/0x5c device_suspend+0x170/0x2e8 dpm_suspend+0xa0/0x104 dpm_suspend_start+0x48/0x50 suspend_devices_and_enter+0x7c/0x45c pm_suspend+0x148/0x160 state_store+0xb4/0xf8 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x38/0x48 kernfs_fop_write_iter+0xb4/0x178 vfs_write+0x118/0x178 ksys_write+0x6c/0xd0 __arm64_sys_write+0x14/0x1c invoke_syscall.constprop.0+0x64/0xb0 do_el0_svc+0x90/0xb0 el0_svc+0x18/0x44 el0t_64_sync_handler+0x88/0x124 el0t_64_sync+0x150/0x154 Code: 88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39723 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfs: Fix unbuffered write error handlingIf all the subrequests in an unbuffered write stream fail, the subrequestcollector doesn't update the stream->transferred value and it retains itsinitial LONG_MAX value. Unfortunately, if all active streams fail, then wetake the smallest value of { LONG_MAX, LONG_MAX, ... } as the value to setin wreq->transferred - which is then returned from ->write_iter().LONG_MAX was chosen as the initial value so that all the streams can bequickly assessed by taking the smallest value of all stream->transferred -but this only works if we've set any of them.Fix this by adding a flag to indicate whether the value instream->transferred is valid and checking that when we integrate thevalues. stream->transferred can then be initialised to zero.This was found by running the generic/750 xfstest against cifs withcache=none. It splices data to the target file. Once (if) it has used upall the available scratch space, the writes start failing with ENOSPC.This causes ->write_iter() to fail. However, it was returningwreq->transferred, i.e. LONG_MAX, rather than an error (because it thoughtthe amount transferred was non-zero) and iter_file_splice_write() wouldthen try to clean up that amount of pipe bufferage - leading to an oopswhen it overran. The kernel log showed: CIFS: VFS: Send error in write = -28followed by: BUG: kernel NULL pointer dereference, address: 0000000000000008with: RIP: 0010:iter_file_splice_write+0x3a4/0x520 do_splice+0x197/0x4e0or: RIP: 0010:pipe_buf_release (include/linux/pipe_fs_i.h:282) iter_file_splice_write (fs/splice.c:755)Also put a warning check into splice to announce if ->write_iter() returnedthat it had written more than it was asked to.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39724 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250: fix panic due to PSLVERRWhen the PSLVERR_RESP_EN parameter is set to 1, the device generatesan error response if an attempt is made to read an empty RBR (ReceiveBuffer Register) while the FIFO is enabled.In serial8250_do_startup(), calling serial_port_out(port, UART_LCR,UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokesdw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latterfunction enables the FIFO via serial_out(p, UART_FCR, p->fcr).Execution proceeds to the serial_port_in(port, UART_RX).This satisfies the PSLVERR trigger condition.When another CPU (e.g., using printk()) is accessing the UART (UARTis busy), the current CPU fails the check (value & ~UART_LCR_SPAR) ==(lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enterdw8250_force_idle().Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lockto fix this issue.Panic backtrace:[ 0.442336] Oops - unknown exception [#1][ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a[ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e...[ 0.442416] console_on_rootfs+0x26/0x70

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39726 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/ism: fix concurrency management in ism_cmd()The s390x ISM device data sheet clearly states that only onerequest-response sequence is allowable per ISM function at any point intime. Unfortunately as of today the s390/ism driver in Linux does nothonor that requirement. This patch aims to rectify that.This problem was discovered based on Aliaksei's bug report which statesthat for certain workloads the ISM functions end up entering error state(with PEC 2 as seen from the logs) after a while and as a consequenceconnections handled by the respective function break, and for futureconnection requests the ISM device is not considered -- given it is in adysfunctional state. During further debugging PEC 3A was observed aswell.A kernel message like[ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61ais a reliable indicator of the stated function entering error statewith PEC 2. Let me also point out that a kernel message like[ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recoveryis a reliable indicator that the ISM function won't be auto-recoveredbecause the ISM driver currently lacks support for it.On a technical level, without this synchronization, commands (inputs tothe FW) may be partially or fully overwritten (corrupted) by another CPUtrying to issue commands on the same function. There is hard evidence thatthis can lead to DMB token values being used as DMB IOVAs, leading toPEC 2 PCI events indicating invalid DMA. But this is only one of thefailure modes imaginable. In theory even completely losing one commandand executing another one twice and then trying to interpret the outputsas if the command we intended to execute was actually executed and notthe other one is also possible. Frankly, I don't feel confident aboutproviding an exhaustive list of possible consequences.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39727 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: swap: fix potential buffer overflow in setup_clusters()In setup_swap_map(), we only ensure badpages are in range (0, last_page]. As maxpages might be < last_page, setup_clusters() will encounter a bufferoverflow when a badpage is >= maxpages.Only call inc_cluster_info_page() for badpage which is < maxpages to fixthe issue.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39730 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()The function needs to check the minimal filehandle length before it canaccess the embedded filehandle.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39732 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask()ath11k_mac_disable_peer_fixed_rate() is passed as the iterator toieee80211_iterate_stations_atomic(). Note in this case the iterator isrequired to be atomic, however ath11k_mac_disable_peer_fixed_rate() doesnot follow it as it might sleep. Consequently below warning is seen:BUG: sleeping function called from invalid context at wmi.c:304Call Trace: dump_stack_lvl __might_resched.cold ath11k_wmi_cmd_send ath11k_wmi_set_peer_param ath11k_mac_disable_peer_fixed_rate ieee80211_iterate_stations_atomic ath11k_mac_op_set_bitrate_mask.coldChange to ieee80211_iterate_stations_mtx() to fix this issue.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39744 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Fix rcu_read_unlock() deadloop due to IRQ workDuring rcu_read_unlock_special(), if this happens during irq_exit(), wecan lockup if an IPI is issued. This is because the IPI itself triggersthe irq_exit() path causing a recursive lock up.This is precisely what Xiongfeng found when invoking a BPF program onthe trace_tick_stop() tracepoint As shown in the trace below. Fix bymanaging the irq_work state correctly.irq_exit() __irq_exit_rcu() /* in_hardirq() returns false after this */ preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() tick_nohz_stop_sched_tick() trace_tick_stop() /* a bpf prog is hooked on this trace point */ __bpf_trace_tick_stop() bpf_trace_run2() rcu_read_unlock_special() /* will send a IPI to itself */ irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);A simple reproducer can also be obtained by doing the following intick_irq_exit(). It will hang on boot without the patch: static inline void tick_irq_exit(void) { + rcu_read_lock(); + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); + rcu_read_unlock(); +[neeraj: Apply Frederic's suggested fix for PREEMPT_RT]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39747 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: Add error handling for krealloc in metadata setupFunction msm_ioctl_gem_info_set_metadata() now checks for kreallocfailure and returns -ENOMEM, avoiding potential NULL pointer dereference.Explicitly avoids __GFP_NOFAIL due to deadlock risks and allocation constraints.Patchwork: https://patchwork.freedesktop.org/patch/661235/

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39748 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Forget ranges when refining tnum after JSETSyzbot reported a kernel warning due to a range invariant violation onthe following BPF program. 0: call bpf_get_netns_cookie 1: if r0 == 0 goto 2: if r0 & Oxffffffff goto The issue is on the path where we fall through both jumps.That path is unreachable at runtime: after insn 1, we know r0 != 0, butwith the sign extension on the jset, we would only fallthrough insn 2if r0 == 0. Unfortunately, is_branch_taken() isn't currently able tofigure this out, so the verifier walks all branches. The verifier thenrefines the register bounds using the second condition and we endup with inconsistent bounds on this unreachable path: 1: if r0 == 0 goto r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2: if r0 & 0xffffffff goto r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0) r0 after reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0)Improving the range refinement for JSET to cover all cases is tricky. Wealso don't expect many users to rely on JSET given LLVM doesn't generatethose instructions. So instead of improving the range refinement forJSETs, Eduard suggested we forget the ranges whenever we're narrowingtnums after a JSET. This patch implements that approach.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39749 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Protect ->defer_qs_iw_pending from data raceOn kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() isinvoked within an interrupts-disabled region of code [1], it will invokercu_read_unlock_special(), which uses an irq-work handler to force thesystem to notice when the RCU read-side critical section actually ends.That end won't happen until interrupts are enabled at the soonest.In some kernels, such as those booted with rcutree.use_softirq=y, theirq-work handler is used unconditionally.The per-CPU rcu_data structure's ->defer_qs_iw_pending field isupdated by the irq-work handler and is both read and updated byrcu_read_unlock_special(). This resulted in the following KCSAN splat:------------------------------------------------------------------------BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_specialread to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30no locks held by irq_work/8/88.irq event stamp: 200272hardirqs last enabled at (200272): [] finish_task_switch+0x131/0x320hardirqs last disabled at (200271): [] __schedule+0x129/0xd70softirqs last enabled at (0): [] copy_process+0x4df/0x1cc0softirqs last disabled at (0): [<0000000000000000>] 0x0------------------------------------------------------------------------The problem is that irq-work handlers run with interrupts enabled, whichmeans that rcu_preempt_deferred_qs_handler() could be interrupted,and that interrupt handler might contain an RCU read-side criticalsection, which might invoke rcu_read_unlock_special(). In the strictKCSAN mode of operation used by RCU, this constitutes a data race onthe ->defer_qs_iw_pending field.This commit therefore disables interrupts across the portion of thercu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pendingfield. This suffices because this handler is not a fast path.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39754 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/smaps: fix race between smaps_hugetlb_range and migrationsmaps_hugetlb_range() handles the pte without holdling ptl, and may beconcurrenct with migration, leaing to BUG_ON in pfn_swap_entry_to_page(). The race is as follows.smaps_hugetlb_range migrate_pages huge_ptep_get remove_migration_ptes folio_unlock pfn_swap_entry_folio BUG_ONTo fix it, hold ptl lock in smaps_hugetlb_range().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39756 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs: Prevent file descriptor table allocations exceeding INT_MAXWhen sysctl_nr_open is set to a very high value (for example, 1073741816as set by systemd), processes attempting to use file descriptors nearthe limit can trigger massive memory allocation attempts that exceedINT_MAX, resulting in a WARNING in mm/slub.c: WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288This happens because kvmalloc_array() and kvmalloc() check if therequested size exceeds INT_MAX and emit a warning when the allocation isnot flagged with __GFP_NOWARN.Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and aprocess calls dup2(oldfd, 1073741880), the kernel attempts to allocate:- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes- Multiple bitmaps: ~400MB- Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)Reproducer:1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open2. Run a program that uses a high file descriptor: #include #include int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; }3. Observe WARNING in dmesg at mm/slub.c:5027systemd commit a8b627a introduced automatic bumping of fs.nr_open to themaximum possible value. The rationale was that systems with memorycontrol groups (memcg) no longer need separate file descriptor limitssince memory is properly accounted. However, this change overlookedthat:1. The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting2. Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations3. The resulting allocations (>8GB) are impractical and will always failsystemd's algorithm starts with INT_MAX and keeps halving the valueuntil the kernel accepts it. On most systems, this results in nr_openbeing set to 1073741816 (0x3ffffff8), which is just under 1GB of filedescriptors.While processes rarely use file descriptors near this limit in normaloperation, certain selftests (liketools/testing/selftests/core/unshare_test.c) and programs that test filedescriptor limits can trigger this issue.Fix this by adding a check in alloc_fdtable() to ensure the requestedallocation size does not exceed INT_MAX. This causes the operation tofail with -EMFILE instead of triggering a kernel warning and avoids theimpractical >8GB memory allocation request.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39757 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Validate UAC3 cluster segment descriptorsUAC3 class segment descriptors need to be verified whether their sizesmatch with the declared lengths and whether they fit with theallocated buffer sizes, too. Otherwise malicious firmware may lead tothe unexpected OOB accesses.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39758 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpagesEver since commit c2ff29e99a76 ("siw: Inline do_tcp_sendpages()"),we have been doing this:static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset, size_t size)[...] /* Calculate the number of bytes we need to push, for this page * specifically */ size_t bytes = min_t(size_t, PAGE_SIZE - offset, size); /* If we can't splice it, then copy it in, as normal */ if (!sendpage_ok(page[i])) msg.msg_flags &= ~MSG_SPLICE_PAGES; /* Set the bvec pointing to the page, with len $bytes */ bvec_set_page(&bvec, page[i], bytes, offset); /* Set the iter to $size, aka the size of the whole sendpages (!!!) */ iov_iter_bvec(&msg.msg_iter, ITER_SOURCE, &bvec, 1, size);try_page_again: lock_sock(sk); /* Sendmsg with $size size (!!!) */ rv = tcp_sendmsg_locked(sk, &msg, size);This means we've been sending oversized iov_iters and tcp_sendmsg callsfor a while. This has a been a benign bug because sendpage_ok() alwaysreturned true. With the recent slab allocator changes being slowlyintroduced into next (that disallow sendpage on large kmallocallocations), we have recently hit out-of-bounds crashes, due to slightdifferences in iov_iter behavior between the MSG_SPLICE_PAGES and"regular" copy paths:(MSG_SPLICE_PAGES)skb_splice_from_iter iov_iter_extract_pages iov_iter_extract_bvec_pages uses i->nr_segs to correctly stop in its tracks before OoB'ing everywhere skb_splice_from_iter gets a "short" read(!MSG_SPLICE_PAGES)skb_copy_to_page_nocache copy=iov_iter_count [...] copy_from_iter /* this doesn't help */ if (unlikely(iter->count < len)) len = iter->count; iterate_bvec ... and we run off the bvecsFix this by properly setting the iov_iter's byte count, plus sending thecorrect byte count to tcp_sendmsg_locked.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39764 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: remove refcounting in expectation dumpersSame pattern as previous patch: do not keep the expectation objectalive via refcount, only store a cookie value and then use thatas the skip hint for dump resumption.AFAICS this has the same issue as the one resolved in the conntrackdumper, when we do if (!refcount_inc_not_zero(&exp->use))to increment the refcount, there is a chance that exp == last, whichcauses a double-increment of the refcount and subsequent memory leak.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39765 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: timer: fix ida_free call while not allocatedIn the snd_utimer_create() function, if the kasprintf() function returnNULL, snd_utimer_put_id() will be called, finally use ida_free()to free the unallocated id 0.the syzkaller reported the following information: ------------[ cut here ]------------ ida_free called for id=0 which is not allocated. WARNING: CPU: 1 PID: 1286 at lib/idr.c:592 ida_free+0x1fd/0x2f0 lib/idr.c:592 Modules linked in: CPU: 1 UID: 0 PID: 1286 Comm: syz-executor164 Not tainted 6.15.8 #3 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014 RIP: 0010:ida_free+0x1fd/0x2f0 lib/idr.c:592 Code: f8 fc 41 83 fc 3e 76 69 e8 70 b2 f8 (...) RSP: 0018:ffffc900007f79c8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 1ffff920000fef3b RCX: ffffffff872176a5 RDX: ffff88800369d200 RSI: 0000000000000000 RDI: ffff88800369d200 RBP: 0000000000000000 R08: ffffffff87ba60a5 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f6f1abc1740(0000) GS:ffff8880d76a0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6f1ad7a784 CR3: 000000007a6e2000 CR4: 00000000000006f0 Call Trace: snd_utimer_put_id sound/core/timer.c:2043 [inline] [snd_timer] snd_utimer_create+0x59b/0x6a0 sound/core/timer.c:2184 [snd_timer] snd_utimer_ioctl_create sound/core/timer.c:2202 [inline] [snd_timer] __snd_timer_user_ioctl.isra.0+0x724/0x1340 sound/core/timer.c:2287 [snd_timer] snd_timer_user_ioctl+0x75/0xc0 sound/core/timer.c:2298 [snd_timer] 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+0x198/0x200 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x7b/0x160 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...]The utimer->id should be set properly before the kasprintf() function,ensures the snd_utimer_put_id() function will free the allocated id.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39766 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limitThe following setup can trigger a WARNING in htb_activate due tothe condition: !cl->leaf.q->q.qlentc qdisc del dev lo roottc qdisc add dev lo root handle 1: htb default 1tc class add dev lo parent 1: classid 1:1 \ htb rate 64bittc qdisc add dev lo parent 1:1 handle f: \ cake memlimit 1bping -I lo -f -c1 -s64 -W0.001 127.0.0.1This is because the low memlimit leads to a low buffer_limit, whichcauses packet dropping. However, cake_enqueue still returnsNET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with anempty child qdisc. We should return NET_XMIT_CN when packets aredropped from the same tin and flow.I do not believe return value of NET_XMIT_CN is necessary for packetdrops in the case of ack filtering, as that is meant to optimizeperformance, not to signal congestion.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39767 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: Optimize module load time by optimizing PLT/GOT countingWhen enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD andCONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock,the relevant logs are as follows:rcu: INFO: rcu_sched self-detected stall on CPU...Call Trace:[<900000000024f9e4>] show_stack+0x5c/0x180[<90000000002482f4>] dump_stack_lvl+0x94/0xbc[<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280[<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88[<9000000000396c34>] update_process_times+0xb4/0x150[<90000000003b2474>] tick_nohz_handler+0xf4/0x250[<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428[<9000000000399b2c>] hrtimer_interrupt+0x214/0x538[<9000000000253634>] constant_timer_interrupt+0x64/0x80[<9000000000349938>] __handle_irq_event_percpu+0x78/0x1a0[<9000000000349a78>] handle_irq_event_percpu+0x18/0x88[<9000000000354c00>] handle_percpu_irq+0x90/0xf0[<9000000000348c74>] handle_irq_desc+0x94/0xb8[<9000000001012b28>] handle_cpu_irq+0x68/0xa0[<9000000001def8c0>] handle_loongarch_irq+0x30/0x48[<9000000001def958>] do_vint+0x80/0xd0[<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0[<90000000006344f4>] __asan_load8+0x4c/0x120[<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8[<90000000003895f0>] load_module+0x9e0/0x2958[<900000000038b770>] __do_sys_init_module+0x208/0x2d0[<9000000001df0c34>] do_syscall+0x94/0x190[<900000000024d6fc>] handle_syscall+0xbc/0x158After analysis, this is because the slow speed of loading the amdgpumodule leads to the long time occupation of the cpu and then the softdeadlock.When loading a module, module_frob_arch_sections() tries to figure outthe number of PLTs/GOTs that will be needed to handle all the RELAs. Itwill call the count_max_entries() to find in an out-of-order date whichcounting algorithm has O(n^2) complexity.To make it faster, we sort the relocation list by info and addend. Thatway, to check for a duplicate relocation, it just needs to compare withthe previous entry. This reduces the complexity of the algorithm to O(n log n), as done in commit d4e0340919fb ("arm64/module: Optimize moduleload time by optimizing PLT counting"). This gives sinificant reductionin module load time for modules with large number of relocations.After applying this patch, the soft deadlock problem has been solved,and the kernel starts normally without "Call Trace".Using the default configuration to test some modules, the results are asfollows:Module Sizeip_tables 36Kfat 143Kradeon 2.5MBamdgpu 16MBWithout this patch:Module Module load time (ms) Count(PLTs/GOTs)ip_tables 18 59/6fat 0 162/14radeon 54 1221/84amdgpu 1411 4525/1098With this patch:Module Module load time (ms) Count(PLTs/GOTs)ip_tables 18 59/6fat 0 162/14radeon 22 1221/84amdgpu 45 4525/1098

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39770 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUMWhen performing Generic Segmentation Offload (GSO) on an IPv6 packet thatcontains extension headers, the kernel incorrectly requests checksum offloadif the egress device only advertises NETIF_F_IPV6_CSUM feature, which hasa strict contract: it supports checksum offload only for plain TCP or UDPover IPv6 and explicitly does not support packets with extension headers.The current GSO logic violates this contract by failing to disable the featurefor packets with extension headers, such as those used in GREoIPv6 tunnels.This violation results in the device being asked to perform an operationit cannot support, leading to a `skb_warn_bad_offload` warning and a collapseof network throughput. While device TSO/USO is correctly bypassed in favorof software GSO for these packets, the GSO stack must be explicitly told notto request checksum offload.Mask NETIF_F_IPV6_CSUM, NETIF_F_TSO6 and NETIF_F_GSO_UDP_L4in gso_features_check if the IPv6 header contains extension headers to computechecksum in software.The exception is a BIG TCP extension, which, as stated in commit68e068cabd2c6c53 ("net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets"):"The feature is only enabled on devices that support BIG TCP TSO.The header is only present for PF_PACKET taps like tcpdump,and not transmitted by physical devices."kernel log output (truncated):WARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skb_warn_bad_offload+0x81/0x140...Call Trace: skb_checksum_help+0x12a/0x1f0 validate_xmit_skb+0x1a3/0x2d0 validate_xmit_skb_list+0x4f/0x80 sch_direct_xmit+0x1a2/0x380 __dev_xmit_skb+0x242/0x670 __dev_queue_xmit+0x3fc/0x7f0 ip6_finish_output2+0x25e/0x5d0 ip6_finish_output+0x1fc/0x3f0 ip6_tnl_xmit+0x608/0xc00 [ip6_tunnel] ip6gre_tunnel_xmit+0x1c0/0x390 [ip6_gre] dev_hard_start_xmit+0x63/0x1c0 __dev_queue_xmit+0x6d0/0x7f0 ip6_finish_output2+0x214/0x5d0 ip6_finish_output+0x1fc/0x3f0 ip6_xmit+0x2ca/0x6f0 ip6_finish_output+0x1fc/0x3f0 ip6_xmit+0x2ca/0x6f0 inet6_csk_xmit+0xeb/0x150 __tcp_transmit_skb+0x555/0xa80 tcp_write_xmit+0x32a/0xe90 tcp_sendmsg_locked+0x437/0x1110 tcp_sendmsg+0x2f/0x50...skb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0eskb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00skb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00skb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00skb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00skb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00skb linear: 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9skb linear: 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01skb linear: 00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39772 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/hisilicon/hibmc: fix the hibmc loaded failed bugWhen hibmc loaded failed, the driver use hibmc_unload to free theresource, but the mutexes in mode.config are not init, which willaccess an NULL pointer. Just change goto statement to return, becausehibnc_hw_init() doesn't need to free anything.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39773 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix soft lockup in br_multicast_query_expired()When set multicast_query_interval to a large value, the local variable'time' in br_multicast_send_query() may overflow. If the time is smallerthan jiffies, the timer will expire immediately, and then call mod_timer()again, which creates a loop and may trigger the following soft lockupissue. watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70 __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90 This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 upThe multicast_startup_query_interval can also cause this issue. Similar tothe commit 99b40610956a ("net: bridge: mcast: add and enforce queryinterval minimum"), add check for the query interval maximum to fix thisissue.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39775 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/mremap: fix WARN with uffd that has remap events disabledRegistering userfaultd on a VMA that spans at least one PMD and thenmremap()'ing that VMA can trigger a WARN when recovering from a failedpage table move due to a page table allocation error.The code ends up doing the right thing (recurse, avoiding moving actualpage tables), but triggering that WARN is unpleasant:WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_normal_pmd mm/mremap.c:357 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_pgt_entry mm/mremap.c:595 [inline]WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_page_tables+0x3832/0x44a0 mm/mremap.c:852Modules linked in:CPU: 2 UID: 0 PID: 6133 Comm: syz.0.19 Not tainted 6.17.0-rc1-syzkaller-00004-g53e760d89498 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:move_normal_pmd mm/mremap.c:357 [inline]RIP: 0010:move_pgt_entry mm/mremap.c:595 [inline]RIP: 0010:move_page_tables+0x3832/0x44a0 mm/mremap.c:852Code: ...RSP: 0018:ffffc900037a76d8 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000032930007 RCX: ffffffff820c6645RDX: ffff88802e56a440 RSI: ffffffff820c7201 RDI: 0000000000000007RBP: ffff888037728fc0 R08: 0000000000000007 R09: 0000000000000000R10: 0000000032930007 R11: 0000000000000000 R12: 0000000000000000R13: ffffc900037a79a8 R14: 0000000000000001 R15: dffffc0000000000FS: 000055556316a500(0000) GS:ffff8880d68bc000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30863fff CR3: 0000000050171000 CR4: 0000000000352ef0Call Trace: copy_vma_and_data+0x468/0x790 mm/mremap.c:1215 move_vma+0x548/0x1780 mm/mremap.c:1282 mremap_to+0x1b7/0x450 mm/mremap.c:1406 do_mremap+0xfad/0x1f80 mm/mremap.c:1921 __do_sys_mremap+0x119/0x170 mm/mremap.c:1977 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/0x7fRIP: 0033:0x7f00d0b8ebe9Code: ...RSP: 002b:00007ffe5ea5ee98 EFLAGS: 00000246 ORIG_RAX: 0000000000000019RAX: ffffffffffffffda RBX: 00007f00d0db5fa0 RCX: 00007f00d0b8ebe9RDX: 0000000000400000 RSI: 0000000000c00000 RDI: 0000200000000000RBP: 00007ffe5ea5eef0 R08: 0000200000c00000 R09: 0000000000000000R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000002R13: 00007f00d0db5fa0 R14: 00007f00d0db5fa0 R15: 0000000000000005 The underlying issue is that we recurse during the original page tablemove, but not during the recovery move.Fix it by checking for both VMAs and performing the check before thepmd_none() sanity check.Add a new helper where we perform+document that check for the PMD and PUDlevel.Thanks to Harry for bisecting.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39776 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/debug_vm_pgtable: clear page table entries at destroy_args()The mm/debug_vm_pagetable test allocates manually page table entries forthe tests it runs, using also its manually allocated mm_struct. That initself is ok, but when it exits, at destroy_args() it fails to clear thoseentries with the *_clear functions.The problem is that leaves stale entries. If another process allocates anmm_struct with a pgd at the same address, it may end up running into thestale entry. This is happening in practice on a debug kernel withCONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extradebugging I added (it prints a warning trace if pgtables_bytes goesnegative, in addition to the warning at check_mm() function):[ 2.539353] debug_vm_pgtable: [get_random_vaddr ]: random_vaddr is 0x7ea247140000[ 2.539366] kmem_cache info[ 2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508[ 2.539447] debug_vm_pgtable: [init_args ]: args->mm is 0x000000002267cc9e(...)[ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0[ 2.552816] Modules linked in:[ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY[ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries[ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90[ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debug_vm2.el10.ppc64le+debug)[ 2.552899] MSR: 800000000282b033 CR: 24002822 XER: 0000000a[ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0[ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001[ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff[ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000[ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb[ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0[ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000[ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001[ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760[ 2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0[ 2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0[ 2.553199] Call Trace:[ 2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable)[ 2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0[ 2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570[ 2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650[ 2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290[ 2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0[ 2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870[ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150[ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50[ 2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0[ 2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec(...)[ 2.558892] ---[ end trace 0000000000000000 ]---[ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1[ 2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144Here the modprobe process ended up with an allocated mm_struct from themm_struct slab that was used before by the debug_vm_pgtable test. That isnot a problem, since the mm_stru---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39779 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: subpage: keep TOWRITE tag until folio is cleanedbtrfs_subpage_set_writeback() calls folio_start_writeback() the first timea folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tageven if there are still dirty blocks in the folio. This can break orderingguarantees, such as those required by btrfs_wait_ordered_extents().That ordering breakage leads to a real failure. For example, runninggeneric/464 on a zoned setup will hit the following ASSERT. This happensbecause the broken ordering fails to flush existing dirty pages before thefile size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode orfor compressed writes, it locks several folios for delalloc and startswriting them out. Let's call the last locked folio folio X. Suppose thewrite range only partially covers folio X, leaving some pages dirty.Process A calls btrfs_subpage_set_writeback() when building a bio. Thisfunction call clears the TOWRITE tag of folio X, whose size = 8K andthe block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range.Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. Itcalls tag_pages_for_writeback() to tag dirty folios withPAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then,B collects tagged folios using filemap_get_folios_tag() and must wait forfolio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE)However, between tagging and collecting, process A may callbtrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY)As a result, process B won't see folio X in its batch, and returns withoutwaiting for it. This breaks the WB_SYNC_ALL ordering requirement.Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retainsthe TOWRITE tag. We now manually clear the tag only after the folio becomesclean, via the xas operation.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39780 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/ext: Fix invalid task state transitions on class switchWhen enabling a sched_ext scheduler, we may trigger invalid task statetransitions, resulting in warnings like the following (which can beeasily reproduced by running the hotplug selftest in a loop): sched_ext: Invalid task state transition 0 -> 3 for fish[770] WARNING: CPU: 18 PID: 787 at kernel/sched/ext.c:3862 scx_set_task_state+0x7c/0xc0 ... RIP: 0010:scx_set_task_state+0x7c/0xc0 ... Call Trace: scx_enable_task+0x11f/0x2e0 switching_to_scx+0x24/0x110 scx_enable.isra.0+0xd14/0x13d0 bpf_struct_ops_link_create+0x136/0x1a0 __sys_bpf+0x1edd/0x2c30 __x64_sys_bpf+0x21/0x30 do_syscall_64+0xbb/0x370 entry_SYSCALL_64_after_hwframe+0x77/0x7fThis happens because we skip initialization for tasks that are alreadydead (with their usage counter set to zero), but we don't exclude themduring the scheduling class transition phase.Fix this by also skipping dead tasks during class swiching, preventinginvalid task state transitions.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39782 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: prevent softlockup in jbd2_log_do_checkpoint()Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()periodically release j_list_lock after processing a batch of buffers toavoid long hold times on the j_list_lock. However, since both functionscontend for j_list_lock, the combined time spent waiting and processingcan be significant.jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() whenneed_resched() is true to avoid softlockups during prolonged operations.But jbd2_log_do_checkpoint() only exits its loop when need_resched() istrue, relying on potentially sleeping functions like __flush_batch() orwait_on_buffer() to trigger rescheduling. If those functions do not sleep,the kernel may hit a softlockup.watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017Workqueue: writeback wb_workfn (flush-7:2)pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : native_queued_spin_lock_slowpath+0x358/0x418lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2] __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoidsoftlockup.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39783 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: Fix configfs group list head handlingDoing a list_del() on the epf_group field of struct pci_epf_driver inpci_epf_remove_cfs() is not correct as this field is a list head, nota list entry. This list_del() call triggers a KASAN warning when anendpoint function driver which has a configfs attribute group is torndown:==================================================================BUG: KASAN: slab-use-after-free in pci_epf_remove_cfs+0x17c/0x198Write of size 8 at addr ffff00010f4a0d80 by task rmmod/319CPU: 3 UID: 0 PID: 319 Comm: rmmod Not tainted 6.16.0-rc2 #1 NONEHardware name: Radxa ROCK 5B (DT)Call trace:show_stack+0x2c/0x84 (C)dump_stack_lvl+0x70/0x98print_report+0x17c/0x538kasan_report+0xb8/0x190__asan_report_store8_noabort+0x20/0x2cpci_epf_remove_cfs+0x17c/0x198pci_epf_unregister_driver+0x18/0x30nvmet_pci_epf_cleanup_module+0x24/0x30 [nvmet_pci_epf]__arm64_sys_delete_module+0x264/0x424invoke_syscall+0x70/0x260el0_svc_common.constprop.0+0xac/0x230do_el0_svc+0x40/0x58el0_svc+0x48/0xdcel0t_64_sync_handler+0x10c/0x138el0t_64_sync+0x198/0x19c...Remove this incorrect list_del() call from pci_epf_remove_cfs().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39789 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: x86/aegis - Add missing error checksThe skcipher_walk functions can allocate memory and can fail, sochecking for errors is necessary.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39800 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: abort transaction on unexpected eb generation at btrfs_copy_root()If we find an unexpected generation for the extent buffer we are cloningat btrfs_copy_root(), we just WARN_ON() and don't error out and abort thetransaction, meaning we allow to persist metadata with an unexpectedgeneration. Instead of warning only, abort the transaction and return-EUCLEAN.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39805 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: fix unregister_netdev call order in macb_remove()When removing a macb device, the driver calls phy_exit() beforeunregister_netdev(). This leads to a WARN from kernfs: ------------[ cut here ]------------ kernfs: can not remove 'attached_dev', no directory WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683 Call trace: kernfs_remove_by_name_ns+0xd8/0xf0 sysfs_remove_link+0x24/0x58 phy_detach+0x5c/0x168 phy_disconnect+0x4c/0x70 phylink_disconnect_phy+0x6c/0xc0 [phylink] macb_close+0x6c/0x170 [macb] ... macb_remove+0x60/0x168 [macb] platform_remove+0x5c/0x80 ...The warning happens because the PHY is being exited while the netdevis still registered. The correct order is to unregister the netdevbefore shutting down the PHY and cleaning up the MDIO bus.Fix this by moving unregister_netdev() ahead of phy_exit() inmacb_remove().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39806 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: multitouch: fix slab out-of-bounds access in mt_report_fixup()A malicious HID device can trigger a slab out-of-bounds duringmt_report_fixup() by passing in report descriptor smaller than607 bytes. mt_report_fixup() attempts to patch byte offset 607of the descriptor with 0x25 by first checking if byte offset607 is 0x15 however it lacks bounds checks to verify if thedescriptor is big enough before conducting this check. Fixthis bug by ensuring the descriptor size is at least 608bytes before accessing it.Below is the KASAN splat after the out of bounds access happens:[ 13.671954] ==================================================================[ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110[ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10[ 13.673297][ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3[ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04[ 13.673297] Call Trace:[ 13.673297] [ 13.673297] dump_stack_lvl+0x5f/0x80[ 13.673297] print_report+0xd1/0x660[ 13.673297] kasan_report+0xe5/0x120[ 13.673297] __asan_report_load1_noabort+0x18/0x20[ 13.673297] mt_report_fixup+0x103/0x110[ 13.673297] hid_open_report+0x1ef/0x810[ 13.673297] mt_probe+0x422/0x960[ 13.673297] hid_device_probe+0x2e2/0x6f0[ 13.673297] really_probe+0x1c6/0x6b0[ 13.673297] __driver_probe_device+0x24f/0x310[ 13.673297] driver_probe_device+0x4e/0x220[ 13.673297] __device_attach_driver+0x169/0x320[ 13.673297] bus_for_each_drv+0x11d/0x1b0[ 13.673297] __device_attach+0x1b8/0x3e0[ 13.673297] device_initial_probe+0x12/0x20[ 13.673297] bus_probe_device+0x13d/0x180[ 13.673297] device_add+0xe3a/0x1670[ 13.673297] hid_add_device+0x31d/0xa40[...]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39807 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Add error handling for old state CRTC in atomic_disableIntroduce error handling to address an issue where, after a hotplugevent, the cursor continues to update. This situation can lead to akernel panic due to accessing the NULL `old_state->crtc`.E,g.Unable to handle kernel NULL pointer dereference at virtual addressCall trace: mtk_crtc_plane_disable+0x24/0x140 mtk_plane_atomic_update+0x8c/0xa8 drm_atomic_helper_commit_planes+0x114/0x2c8 drm_atomic_helper_commit_tail_rpm+0x4c/0x158 commit_tail+0xa0/0x168 drm_atomic_helper_commit+0x110/0x120 drm_atomic_commit+0x8c/0xe0 drm_atomic_helper_update_plane+0xd4/0x128 __setplane_atomic+0xcc/0x110 drm_mode_cursor_common+0x250/0x440 drm_mode_cursor_ioctl+0x44/0x70 drm_ioctl+0x264/0x5d8 __arm64_sys_ioctl+0xd8/0x510 invoke_syscall+0x6c/0xe0 do_el0_svc+0x68/0xe8 el0_svc+0x34/0x60 el0t_64_sync_handler+0x1c/0xf8 el0t_64_sync+0x180/0x188Adding NULL pointer checks to ensure stability by preventing operationson an invalid CRTC state.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39808 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()in ntrig_report_version(), hdev parameter passed from hid_probe().sending descriptor to /dev/uhid can make hdev->dev.parent->parent to nullif hdev->dev.parent->parent is null, usb_dev hasinvalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returnedwhen usb_rcvctrlpipe() use usb_dev,it triggerpage fault error for address(0xffffffffffffff58)add null check logic to ntrig_report_version()before calling hid_to_usb_dev()

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39810 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix memory corruption when FW resources change during ifdownbnxt_set_dflt_rings() assumes that it is always called before any TC hasbeen created. So it doesn't take bp->num_tc into account and assumesthat it is always 0 or 1.In the FW resource or capability change scenario, the FW will returnflags in bnxt_hwrm_if_change() that will cause the driver toreinitialize and call bnxt_cancel_reservations(). This will lead tobnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tcmay be greater than 1. This will cause bp->tx_ring[] to be sized toosmall and cause memory corruption in bnxt_alloc_cp_rings().Fix it by properly scaling the TX rings by bp->num_tc in the codepaths mentioned above. Add 2 helper functions to determinebp->tx_nr_rings and bp->tx_nr_rings_per_tc.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39811 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/vm: Clear the scratch_pt pointer on errorAvoid triggering a dereference of an error pointer on cleanup inxe_vm_free_scratch() by clearing any scratch_pt error pointer.(cherry picked from commit 358ee50ab565f3c8ea32480e9d03127a81ba32f8)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39813 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix potential warning in trace_printk_seq during ftrace_dumpWhen calling ftrace_dump_one() concurrently with reading trace_pipe,a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a racecondition.The issue occurs because:CPU0 (ftrace_dump) CPU1 (reader)echo z > /proc/sysrq-trigger!trace_empty(&iter)trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipetrace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULLtrace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size)In the context between trace_empty() and trace_find_next_entry_inc()during ftrace_dump, the ring buffer data was consumed by other readers.This caused trace_find_next_entry_inc to return NULL, failing to populate`iter.seq`. At this point, due to the prior trace_iterator_reset, both`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,the WARN_ON_ONCE condition is triggered.Move the trace_printk_seq() into the if block that checks to make sure thereturn value of trace_find_next_entry_inc() is non-NULL inftrace_dump_one(), ensuring the 'iter.seq' is properly populated beforesubsequent operations.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39816 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/kbuf: always use READ_ONCE() to read ring provided buffer lengthsSince the buffers are mapped from userspace, it is prudent to useREAD_ONCE() to read the value into a local variable, and use that forany other actions taken. Having a stable read of the buffer lengthavoids worrying about it changing after checking, or being read multipletimes.Similarly, the buffer may well change in between it being picked andbeing committed. Ensure the looping for incremental ring buffer commitstops if it hits a zero sized buffer, as no further progress can be madeat that point.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39817 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix slab-out-of-bounds in efivarfs_d_compareObserved on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can becomenegative, leadings to oob. The issue can be triggered by parallellookups using invalid filename: T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list lookup_open d_alloc_parallel __d_lookup_rcu __d_lookup_rcu_op_compare hlist_bl_for_each_entry_rcu // invalid dentry can be retrieved ->d_compare efivarfs_d_compare // oobFix it by checking 'guid' before cmp.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39819 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs/smb: Fix inconsistent refcnt updateA possible inconsistent update of refcount was identified in `smb2_compound_op`.Such inconsistent update could lead to possible resource leaks.Why it is a possible bug:1. In the comment section of the function, it clearly states that thereference to `cfile` should be dropped after calling this function.2. Every control flow path would check and drop the reference to`cfile`, except the patched one.3. Existing callers would not handle refcount update of `cfile` if-ENOMEM is returned.To fix the bug, an extra goto label "out" is added, to make sure that thecleanup logic would always be respected. As the problem is caused by theallocation failure of `vars`, the cleanup logic between label "finished"and "out" can be safely ignored. According to the definition of function`is_replayable_error`, the error code of "-ENOMEM" is not recoverable.Therefore, the replay logic also gets ignored.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39822 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/kbuf: fix signedness in this_len calculationWhen importing and using buffers, buf->len is considered unsigned.However, buf->len is converted to signed int when committing. This canlead to unexpected behavior if the buffer is large enough to beinterpreted as a negative value. Make min_t calculation unsigned.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39823 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: use array_index_nospec with indices that come from guestmin and dest_id are guest-controlled indices. Using array_index_nospec()after the bounds checks clamps these values to mitigate speculative executionside-channels.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39824 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: asus: fix UAF via HID_CLAIMED_INPUT validationAfter hid_hw_start() is called hidinput_connect() will eventually becalled to set up the device with the input layer since theHID_CONNECT_DEFAULT connect mask is used. During hidinput_connect()all input and output reports are processed and corresponding hid_inputsare allocated and configured via hidinput_configure_usages(). Thisprocess involves slot tagging report fields and configuring usagesby setting relevant bits in the capability bitmaps. However it is possiblethat the capability bitmaps are not set at all leading to the subsequenthidinput_has_been_populated() check to fail leading to the freeing of thehid_input and the underlying input device.This becomes problematic because a malicious HID device like aASUS ROG N-Key keyboard can trigger the above scenario via aspecially crafted descriptor which then leads to a user-after-freewhen the name of the freed input device is written to later on afterhid_hw_start(). Below, report 93 intentionally utilises theHID_UP_UNDEFINED Usage Page which is skipped during usageconfiguration, leading to the frees.0x05, 0x0D, // Usage Page (Digitizer)0x09, 0x05, // Usage (Touch Pad)0xA1, 0x01, // Collection (Application)0x85, 0x0D, // Report ID (13)0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00)0x09, 0xC5, // Usage (0xC5)0x15, 0x00, // Logical Minimum (0)0x26, 0xFF, 0x00, // Logical Maximum (255)0x75, 0x08, // Report Size (8)0x95, 0x04, // Report Count (4)0xB1, 0x02, // Feature (Data,Var,Abs)0x85, 0x5D, // Report ID (93)0x06, 0x00, 0x00, // Usage Page (Undefined)0x09, 0x01, // Usage (0x01)0x15, 0x00, // Logical Minimum (0)0x26, 0xFF, 0x00, // Logical Maximum (255)0x75, 0x08, // Report Size (8)0x95, 0x1B, // Report Count (27)0x81, 0x02, // Input (Data,Var,Abs)0xC0, // End CollectionBelow is the KASAN splat after triggering the UAF:[ 21.672709] ==================================================================[ 21.673700] BUG: KASAN: slab-use-after-free in asus_probe+0xeeb/0xf80[ 21.673700] Write of size 8 at addr ffff88810a0ac000 by task kworker/1:2/54[ 21.673700][ 21.673700] CPU: 1 UID: 0 PID: 54 Comm: kworker/1:2 Not tainted 6.16.0-rc4-g9773391cf4dd-dirty #36 PREEMPT(voluntary)[ 21.673700] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014[ 21.673700] Call Trace:[ 21.673700] [ 21.673700] dump_stack_lvl+0x5f/0x80[ 21.673700] print_report+0xd1/0x660[ 21.673700] kasan_report+0xe5/0x120[ 21.673700] __asan_report_store8_noabort+0x1b/0x30[ 21.673700] asus_probe+0xeeb/0xf80[ 21.673700] hid_device_probe+0x2ee/0x700[ 21.673700] really_probe+0x1c6/0x6b0[ 21.673700] __driver_probe_device+0x24f/0x310[ 21.673700] driver_probe_device+0x4e/0x220[...][ 21.673700][ 21.673700] Allocated by task 54:[ 21.673700] kasan_save_stack+0x3d/0x60[ 21.673700] kasan_save_track+0x18/0x40[ 21.673700] kasan_save_alloc_info+0x3b/0x50[ 21.673700] __kasan_kmalloc+0x9c/0xa0[ 21.673700] __kmalloc_cache_noprof+0x139/0x340[ 21.673700] input_allocate_device+0x44/0x370[ 21.673700] hidinput_connect+0xcb6/0x2630[ 21.673700] hid_connect+0xf74/0x1d60[ 21.673700] hid_hw_start+0x8c/0x110[ 21.673700] asus_probe+0x5a3/0xf80[ 21.673700] hid_device_probe+0x2ee/0x700[ 21.673700] really_probe+0x1c6/0x6b0[ 21.673700] __driver_probe_device+0x24f/0x310[ 21.673700] driver_probe_device+0x4e/0x220[...][ 21.673700][ 21.673700] Freed by task 54:[ 21.673700] kasan_save_stack+0x3d/0x60[ 21.673700] kasan_save_track+0x18/0x40[ 21.673700] kasan_save_free_info+0x3f/0x60[ 21.673700] __kasan_slab_free+0x3c/0x50[ 21.673700] kfre---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39828 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().syzbot reported the splat below. [0]When atmtcp_v_open() or atmtcp_v_close() is called via connect()or close(), atmtcp_send_control() is called to send an in-kernelspecial message.The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.The notable thing is struct atmtcp_control is uAPI but has aspace for an in-kernel pointer. struct atmtcp_control { struct atmtcp_hdr hdr; /* must be first */ ... atm_kptr_t vcc; /* both directions */ ... } __ATM_API_ALIGN; typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;The special message is processed in atmtcp_recv_control() calledfrom atmtcp_c_send().atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths: 1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg()The problem is sendmsg() does not validate the message length anduserspace can abuse atmtcp_recv_control() to overwrite any kptrby atmtcp_control.Let's add a new ->pre_send() hook to validate messages from sendmsg().[0]:Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTIKASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4cRSP: 0018:ffffc90003f5f810 EFLAGS: 00010203RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068cRBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0ddR10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffffFS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0Call Trace: vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 ____sys_sendmsg+0x505/0x830 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 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/0x7fRIP: 0033:0x7f8d7e96a4a9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702fR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10acR13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 Modules linked in:

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39829 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:trace/fgraph: Fix the warning caused by missing unregister notifierThis warning was triggered during testing on v6.16:notifier callback ftrace_suspend_notifier_call already registeredWARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0...Call Trace: blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7fWhen writing to the function_profile_enabled interface, the notifier wasnot unregistered after start_graph_tracing failed, causing a warning thenext time function_profile_enabled was written.Fixed by adding unregister_pm_notifier in the exception path.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39830 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: HWS, Fix memory leak in hws_pool_buddy_init error pathIn the error path of hws_pool_buddy_init(), the buddy allocator cleanupdoesn't free the allocator structure itself, causing a memory leak.Add the missing kfree() to properly release all allocated memory.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39831 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbnic: Move phylink resume out of service_task and into open/closeThe fbnic driver was presenting with the following locking assert comingout of a PM resume:[ 42.208116][ T164] RTNL: assertion failed at drivers/net/phy/phylink.c (2611)[ 42.208492][ T164] WARNING: CPU: 1 PID: 164 at drivers/net/phy/phylink.c:2611 phylink_resume+0x190/0x1e0[ 42.208872][ T164] Modules linked in:[ 42.209140][ T164] CPU: 1 UID: 0 PID: 164 Comm: bash Not tainted 6.17.0-rc2-virtme #134 PREEMPT(full)[ 42.209496][ T164] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014[ 42.209861][ T164] RIP: 0010:phylink_resume+0x190/0x1e0[ 42.210057][ T164] Code: 83 e5 01 0f 85 b0 fe ff ff c6 05 1c cd 3e 02 01 90 ba 33 0a 00 00 48 c7 c6 20 3a 1d a5 48 c7 c7 e0 3e 1d a5 e8 21 b8 90 fe 90 <0f> 0b 90 90 e9 86 fe ff ff e8 42 ea 1f ff e9 e2 fe ff ff 48 89 ef[ 42.210708][ T164] RSP: 0018:ffffc90000affbd8 EFLAGS: 00010296[ 42.210983][ T164] RAX: 0000000000000000 RBX: ffff8880078d8400 RCX: 0000000000000000[ 42.211235][ T164] RDX: 0000000000000000 RSI: 1ffffffff4f10938 RDI: 0000000000000001[ 42.211466][ T164] RBP: 0000000000000000 R08: ffffffffa2ae79ea R09: fffffbfff4b3eb84[ 42.211707][ T164] R10: 0000000000000003 R11: 0000000000000000 R12: ffff888007ad8000[ 42.211997][ T164] R13: 0000000000000002 R14: ffff888006a18800 R15: ffffffffa34c59e0[ 42.212234][ T164] FS: 00007f0dc8e39740(0000) GS:ffff88808f51f000(0000) knlGS:0000000000000000[ 42.212505][ T164] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 42.212704][ T164] CR2: 00007f0dc8e9fe10 CR3: 000000000b56d003 CR4: 0000000000772ef0[ 42.213227][ T164] PKRU: 55555554[ 42.213366][ T164] Call Trace:[ 42.213483][ T164] [ 42.213565][ T164] __fbnic_pm_attach.isra.0+0x8e/0xa0[ 42.213725][ T164] pci_reset_function+0x116/0x1d0[ 42.213895][ T164] reset_store+0xa0/0x100[ 42.214025][ T164] ? pci_dev_reset_attr_is_visible+0x50/0x50[ 42.214221][ T164] ? sysfs_file_kobj+0xc1/0x1e0[ 42.214374][ T164] ? sysfs_kf_write+0x65/0x160[ 42.214526][ T164] kernfs_fop_write_iter+0x2f8/0x4c0[ 42.214677][ T164] ? kernfs_vma_page_mkwrite+0x1f0/0x1f0[ 42.214836][ T164] new_sync_write+0x308/0x6f0[ 42.214987][ T164] ? __lock_acquire+0x34c/0x740[ 42.215135][ T164] ? new_sync_read+0x6f0/0x6f0[ 42.215288][ T164] ? lock_acquire.part.0+0xbc/0x260[ 42.215440][ T164] ? ksys_write+0xff/0x200[ 42.215590][ T164] ? perf_trace_sched_switch+0x6d0/0x6d0[ 42.215742][ T164] vfs_write+0x65e/0xbb0[ 42.215876][ T164] ksys_write+0xff/0x200[ 42.215994][ T164] ? __ia32_sys_read+0xc0/0xc0[ 42.216141][ T164] ? do_user_addr_fault+0x269/0x9f0[ 42.216292][ T164] ? rcu_is_watching+0x15/0xd0[ 42.216442][ T164] do_syscall_64+0xbb/0x360[ 42.216591][ T164] entry_SYSCALL_64_after_hwframe+0x4b/0x53[ 42.216784][ T164] RIP: 0033:0x7f0dc8ea9986A bit of digging showed that we were invoking the phylink_resume as a partof the fbnic_up path when we were enabling the service task while notholding the RTNL lock. We should be enabling this sooner as a part of thendo_open path and then just letting the service task come online later.This will help to enforce the correct locking and brings the phylinkinterface online at the same time as the network interface, instead of at alater time.I tested this on QEMU to verify this was working by putting the system tosleep using "echo mem > /sys/power/state" to put the system to sleep in theguest and then using the command "system_wakeup" in the QEMU monitor.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39832 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix lockdep assertion on sync reset unload eventFix lockdep assertion triggered during sync reset unload event. When thesync reset flow is initiated using the devlink reload fw_activateoption, the PF already holds the devlink lock while handling unloadevent. In this case, delegate sync reset unload event handling back tothe devlink callback process to avoid double-locking and resolve thelockdep warning.Kernel log:WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40[...]Call Trace: mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core] mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core] process_one_work+0x222/0x640 worker_thread+0x199/0x350 kthread+0x10b/0x230 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x8e/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39833 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: hfcpci: Fix warning when deleting uninitialized timerWith CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leadsto the following splat:[ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0[ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0[ 250.218775] Modules linked in: hfcpci(-) mISDN_core[ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)[ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0[ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d[ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286[ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95[ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0[ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39[ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001[ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8[ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000[ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0[ 250.236117] Call Trace:[ 250.236599] [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130[ 250.237920] debug_object_assert_init+0x1f6/0x310[ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10[ 250.239658] ? __lock_acquire+0xdea/0x1c70[ 250.240369] __try_to_del_timer_sync+0x69/0x140[ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10[ 250.242058] ? __timer_delete_sync+0xc6/0x120[ 250.242842] ? lock_acquire+0x30/0x80[ 250.243474] ? __timer_delete_sync+0xc6/0x120[ 250.244262] __timer_delete_sync+0x98/0x120[ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci][ 250.245704] __do_sys_delete_module+0x348/0x510[ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10[ 250.247338] do_syscall_64+0xc1/0x360[ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7fFix this by initializing hfc_tl timer with DEFINE_TIMER macro.Also, use mod_timer instead of manual timeout update.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39834 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: HWS, Fix memory leak in hws_action_get_shared_stc_nic error flowWhen an invalid stc_type is provided, the function allocates memory forshared_stc but jumps to unlock_and_out without freeing it, causing amemory leak.Fix by jumping to free_shared_stc label instead to ensure proper cleanup.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39835 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: do not propagate ENODATA disk errors into xattr codeENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code;namely, that the requested attribute name could not be found.However, a medium error from disk may also return ENODATA. At best,this medium error may escape to userspace as "attribute not found"when in fact it's an IO (disk) error.At worst, we may oops in xfs_attr_leaf_get() when we do: error = xfs_attr_leaf_hasname(args, &bp); if (error == -ENOATTR) { xfs_trans_brelse(args->trans, bp); return error; }because an ENODATA/ENOATTR error from disk leaves us with a null bp,and the xfs_trans_brelse will then null-deref it.As discussed on the list, we really need to modify the lower levelIO functions to trap all disk errors and ensure that we don't letunique errors like this leak up into higher xfs functions - manylike this should be remapped to EIO.However, this patch directly addresses a reported bug in the xattrcode, and should be safe to backport to stable kernels. A larger-scopepatch to handle more unique errors at lower levels can follow later.(Note, prior to 07120f1abdff we did not oops, but we did return thewrong error code to userspace.)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39836 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:efi: stmm: Fix incorrect buffer allocation methodThe communication buffer allocated by setup_mm_hdr() is later on passedto tee_shm_register_kernel_buf(). The latter expects those buffers to becontiguous pages, but setup_mm_hdr() just uses kmalloc(). That can causevarious corruptions or BUGs, specifically since commit 9aec2fb0fd5e("slab: allocate frozen pages"), though it was broken before as well.Fix this by using alloc_pages_exact() instead of kmalloc().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39839 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: fix OOB read/write in network-coding decodebatadv_nc_skb_decode_packet() trusts coded_len and checks only againstskb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducingpayload headroom, and the source skb length is not verified, allowing anout-of-bounds read and a small out-of-bounds write.Validate that coded_len fits within the payload area of both destinationand source sk_buffs before XORing.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39841 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix buffer free/clear order in deferred receive pathFix a use-after-free window by correcting the buffer release sequence inthe deferred receive path. The code freed the RQ buffer first and onlythen cleared the context pointer under the lock. Concurrent paths (e.g.,ABTS and the repost path) also inspect and release the same pointer underthe lock, so the old order could lead to double-free/UAF.Note that the repost path already uses the correct pattern: detach thepointer under the lock, then free it after dropping the lock. Thedeferred path should do the same.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39842 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: prevent release journal inode after journal shutdownBefore calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has alreadybeen executed in ocfs2_dismount_volume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reachesjbd2_journal_release_jbd_inode().ocfs2_dismount_volume()-> ocfs2_delete_osb()-> ocfs2_free_slot_info()-> __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> jbd2_journal_release_jbd_inode(osb->journal->j_journal,Adding osb->journal checks will prevent null-ptr-deref during the aboveexecution path.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39844 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: move page table sync declarations to linux/pgtable.hDuring our internal testing, we started observing intermittent bootfailures when the machine uses 4-level paging and has a large amount ofpersistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It turns out that the kernel panics while initializing vmemmap (structpage array) when the vmemmap region spans two PGD entries, because the newPGD entry is only installed in init_mm.pgd, but not in the page tables ofother tasks.And looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap);In the normal path, vmemmap_populate() in arch/x86/mm/init_64.csynchronizes the top level page table (See commit 9b861528a801 ("x86-64,mem: Update all PGDs for direct mapping and vmemmap mapping changes")) sothat all tasks in the system can see the new vmemmap area.However, when vmemmap_can_optimize() returns true, the optimized pathskips synchronization of top-level page tables. This is becausevmemmap_populate_compound_pages() is implemented in core MM code, whichdoes not handle synchronization of the top-level page tables. Instead,the core MM has historically relied on each architecture to perform thissynchronization manually.We're not the first party to encounter a crash caused by not-sync'd toplevel page tables: earlier this year, Gwan-gyeong Mun attempted to addressthe issue [1] [2] after hitting a kernel panic when x86 code accessed thevmemmap area before the corresponding top-level entries were synced. Atthat time, the issue was believed to be triggered only when struct pagewas enlarged for debugging purposes, and the patch did not get furtherupdates.It turns out that current approach of relying on each arch to handle thepage table sync manually is fragile because 1) it's easy to forget to syncthe top level page table, and 2) it's also easy to overlook that thekernel should not access the vmemmap and direct mapping areas before thesync.# The solution: Make page table sync more code robust and harder to missTo address this, Dave Hansen suggested [3] [4] introducing{pgd,p4d}_populate_kernel() for updating kernel portion of the page tablesand allow each architecture to explicitly perform synchronization wheninstalling top-level entries. With this approach, we no longer need toworry about missing the sync step, reducing the risk of futureregressions.The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used byvmalloc and ioremap to synchronize page tables.pgd_populate_kernel() looks like this:static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd, p4d_t *p4d){ pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr);}It is worth noting that vmalloc() and apply_to_range() carefullysynchronizes page tables by calling p*d_alloc_track() andarch_sync_kernel_mappings(), and thus they are not affected by---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39845 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings()Define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensurepage tables are properly synchronized when calling p*d_populate_kernel().For 5-level paging, synchronization is performed viapgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, sosynchronization is instead performed at the P4D level viap4d_populate_kernel().This fixes intermittent boot failures on systems using 4-level paging anda large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmapbefore sync_global_pgds() [1]: BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmap_set_pmd+0xff/0x230 vmemmap_populate_hugepages+0x176/0x180 vmemmap_populate+0x34/0x80 __populate_section_memmap+0x41/0x90 sparse_add_section+0x121/0x3e0 __add_pages+0xba/0x150 add_pages+0x1d/0x70 memremap_pages+0x3dc/0x810 devm_memremap_pages+0x1c/0x60 xe_devm_add+0x8b/0x100 [xe] xe_tile_init_noalloc+0x6a/0x70 [xe] xe_device_probe+0x48c/0x740 [xe] [... snip ...]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39847 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: fix memory leak in pad_compress_skbIf alloc_skb() fails in pad_compress_skb(), it returns NULL withoutreleasing the old skb. The caller does: skb = pad_compress_skb(ppp, skb); if (!skb) goto drop;drop: kfree_skb(skb);When pad_compress_skb() returns NULL, the reference to the old skb islost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.Align pad_compress_skb() semantics with realloc(): only free the oldskb if allocation and compression succeed. At the call site, use thenew_skb variable so the original skb is not lost when pad_compress_skb()fails.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39849 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result()If the ssid->datalen is more than IEEE80211_MAX_SSID_LEN (32) it wouldlead to memory corruption so add some bounds checking.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39850 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objectsWhen the "proxy" option is enabled on a VXLAN device, the device willsuppress ARP requests and IPv6 Neighbor Solicitation messages if it isable to reply on behalf of the remote host. That is, if a matching andvalid neighbor entry is configured on the VXLAN device whose MAC addressis not behind the "any" remote (0.0.0.0 / ::).The code currently assumes that the FDB entry for the neighbor's MACaddress points to a valid remote destination, but this is incorrect ifthe entry is associated with an FDB nexthop group. This can result in aNPD [1][3] which can be reproduced using [2][4].Fix by checking that the remote destination exists before dereferencingit.[1]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014RIP: 0010:vxlan_xmit+0xb58/0x15f0[...]Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3[3]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014RIP: 0010:vxlan_xmit+0x803/0x1600[...]Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7f383422ec77[4] #!/bin/bash ip address add 2001:db8:1::1/128 dev lo ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39851 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Fix NPD when refreshing an FDB entry with a nexthop objectVXLAN FDB entries can point to either a remote destination or an FDBnexthop group. The latter is usually used in EVPN deployments wherelearning is disabled.However, when learning is enabled, an incoming packet might try torefresh an FDB entry that points to an FDB nexthop group and thereforedoes not have a remote. Such packets should be dropped, but they areonly dropped after dereferencing the non-existent remote, resulting in aNPD [1] which can be reproduced using [2].Fix by dropping such packets earlier. Remove the misleading comment fromfirst_remote_rcu().[1]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014RIP: 0010:vxlan_snoop+0x98/0x1e0[...]Call Trace: vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it justexits the function. This ends up causing a memory-leak:unreferenced object 0xffff0000281a8200 (size 2496): comm "softirq", pid 0, jiffies 4295174684 hex dump (first 32 bytes): 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................ 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............ backtrace (crc 5ebdbe15): kmemleak_alloc+0x44/0xe0 kmem_cache_alloc_noprof+0x248/0x470 sk_prot_alloc+0x48/0x120 sk_clone_lock+0x38/0x3b0 inet_csk_clone_lock+0x34/0x150 tcp_create_openreq_child+0x3c/0x4a8 tcp_v6_syn_recv_sock+0x1c0/0x620 tcp_check_req+0x588/0x790 tcp_v6_rcv+0x5d0/0xc18 ip6_protocol_deliver_rcu+0x2d8/0x4c0 ip6_input_finish+0x74/0x148 ip6_input+0x50/0x118 ip6_sublist_rcv+0x2fc/0x3b0 ipv6_list_rcv+0x114/0x170 __netif_receive_skb_list_core+0x16c/0x200 netif_receive_skb_list_internal+0x1f0/0x2d0This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), whenexiting upon error, inet_csk_prepare_forced_close() and tcp_done() needto be called. They make sure the newsk will end up being correctlyfree'd.tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exitlabel that takes care of things. So, this patch here makes suretcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similarerror-handling and thus fixes the leak for TCP-AO.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix potential invalid access when MAC list is emptylist_first_entry() never returns NULL - if the list is empty, it stillreturns a pointer to an invalid object, leading to potential invalidmemory access when dereferenced.Fix this by using list_first_entry_or_null instead of list_first_entry.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39854 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix NULL access of tx->in_use in ice_ll_ts_intrRecent versions of the E810 firmware have support for an extra interrupt tohandle report of the "low latency" Tx timestamps coming from thespecialized low latency firmware interface. Instead of polling theregisters, software can wait until the low latency interrupt is fired.This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, asit uses the same "ready" bitmap to track which Tx timestamps complete.Unfortunately, the ice_ll_ts_intr() function does not check if thetracker is initialized before its first access. This results in NULLdereference or use-after-free bugs similar to the issues fixed in theice_ptp_ts_irq() function.Fix this by only checking the in_use bitmap (and other fields) if thetracker is marked as initialized. The reset flow will clear the init fieldunder lock before it tears the tracker down, thus preventing anyuse-after-free or NULL access.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync()BUG: kernel NULL pointer dereference, address: 00000000000002ecPGD 0 P4D 0Oops: Oops: 0000 [#1] SMP PTICPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONETainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014Workqueue: smc_hs_wq smc_listen_work [smc]RIP: 0010:smc_ib_is_sg_need_sync+0x9e/0xd0 [smc]...Call Trace: smcr_buf_map_link+0x211/0x2a0 [smc] __smc_buf_create+0x522/0x970 [smc] smc_buf_create+0x3a/0x110 [smc] smc_find_rdma_v2_device_serv+0x18f/0x240 [smc] ? smc_vlan_by_tcpsk+0x7e/0xe0 [smc] smc_listen_find_device+0x1dd/0x2b0 [smc] smc_listen_work+0x30f/0x580 [smc] process_one_work+0x18c/0x340 worker_thread+0x242/0x360 kthread+0xe7/0x220 ret_from_fork+0x13a/0x160 ret_from_fork_asm+0x1a/0x30 If the software RoCE device is used, ibdev->dma_device is a null pointer.As a result, the problem occurs. Null pointer detection is added toprevent problems.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39859 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdogThe ptp_ocp_detach() only shuts down the watchdog timer if it ispending. However, if the timer handler is already running, thetimer_delete_sync() is not called. This leads to race conditionswhere the devlink that contains the ptp_ocp is deallocated whilethe timer handler is still accessing it, resulting in use-after-freebugs. The following details one of the race scenarios.(thread 1) | (thread 2)ptp_ocp_remove() | ptp_ocp_detach() | ptp_ocp_watchdog() if (timer_pending(&bp->watchdog))| bp = timer_container_of() timer_delete_sync() | | devlink_free(devlink) //free | | bp-> //useResolve this by unconditionally calling timer_delete_sync() to ensurethe timer is reliably deactivated, preventing any access after free.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39860 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()syzbot reported the splat below without a repro.In the splat, a single thread calling bt_accept_dequeue() freed skand touched it after that.The root cause would be the racy l2cap_sock_cleanup_listen() calladded by the cited commit.bt_accept_dequeue() is called under lock_sock() except forl2cap_sock_release().Two threads could see the same socket during the list iterationin bt_accept_dequeue(): CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAFDepending on the timing, the other thread could show up in the"Freed by task" part.Let's call l2cap_sock_cleanup_listen() under lock_sock() inl2cap_sock_release().[0]:BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Call Trace: __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:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f2accf8ebe9Code: 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 48RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166fR10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609cR13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 Allocated by task 5326: 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:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39861 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: vhci: Prevent use-after-free by removing debugfs files earlyMove the creation of debugfs files into a dedicated function, and ensurethey are explicitly removed during vhci_release(), before associateddata structures are freed.Previously, debugfs files such as "force_suspend", "force_wakeup", andothers were created under hdev->debugfs but not removed invhci_release(). Since vhci_release() frees the backing vhci_datastructure, any access to these files after release would result inuse-after-free errors.Although hdev->debugfs is later freed in hci_release_dev(), user canaccess files after vhci_data is freed but before hdev->debugfs isreleased.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info workThe brcmf_btcoex_detach() only shuts down the btcoex timer, if theflag timer_on is false. However, the brcmf_btcoex_timerfunc(), whichruns as timer handler, sets timer_on to false. This creates criticalrace conditions:1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc()is executing, it may observe timer_on as false and skip the call totimer_shutdown_sync().2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_infoworker after the cancel_work_sync() has been executed, resulting inuse-after-free bugs.The use-after-free bugs occur in two distinct scenarios, depending onthe timing of when the brcmf_btcoex_info struct is freed relative tothe execution of its worker thread.Scenario 1: Freed before the worker is scheduledThe brcmf_btcoex_info is deallocated before the worker is scheduled.A race condition can occur when schedule_work(&bt_local->work) iscalled after the target memory has been freed. The sequence of eventsis detailed below:CPU0 | CPU1brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USEScenario 2: Freed after the worker is scheduledThe brcmf_btcoex_info is freed after the worker has been scheduledbut before or during its execution. In this case, statements withinthe brcmf_btcoex_handler() - such as the container_of macro andsubsequent dereferences of the brcmf_btcoex_info object will causea use-after-free access. The following timeline illustrates thisscenario:CPU0 | CPU1brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ |To resolve the race conditions, drop the conditional check and calltimer_shutdown_sync() directly. It can deactivate the timer reliably,regardless of its current state. Once stopped, the timer_on state isthen set to false.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39864 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: fix use-after-free in cmp_bss()Following bss_free() quirk introduced in commit 776b3580178f("cfg80211: track hidden SSID networks properly"), adjustcfg80211_update_known_bss() to free the last beacon frameelements only if they're not shared via the corresponding'hidden_beacon_bss' pointer.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39865 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tee: fix NULL pointer dereference in tee_shm_puttee_shm_put have NULL pointer dereference:__optee_disable_shm_cache --> shm = reg_pair_to_ptr(...);//shm maybe return NULL tee_shm_free(shm); --> tee_shm_put(shm);//crashAdd check in tee_shm_put to fix it.panic log:Unable to handle kernel paging request at virtual address 0000000000100ccaMem abort info:ESR = 0x0000000096000004EC = 0x25: DABT (current EL), IL = 32 bitsSET = 0, FnV = 0EA = 0, S1PTW = 0FSC = 0x04: level 0 translation faultData abort info:ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000CM = 0, WnR = 0, TnD = 0, TagAccess = 0GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000[0000000000100cca] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 0000000096000004 [#1] SMPCPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ----6.6.0-39-generic #38Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.010/26/2022pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : tee_shm_put+0x24/0x188lr : tee_shm_free+0x14/0x28sp : ffff001f98f9faf0x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffffx17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0cx8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100ccaCall trace:tee_shm_put+0x24/0x188tee_shm_free+0x14/0x28__optee_disable_shm_cache+0xa8/0x108optee_shutdown+0x28/0x38platform_shutdown+0x28/0x40device_shutdown+0x144/0x2b0kernel_power_off+0x3c/0x80hibernate+0x35c/0x388state_store+0x64/0x80kobj_attr_store+0x14/0x28sysfs_kf_write+0x48/0x60kernfs_fop_write_iter+0x128/0x1c0vfs_write+0x270/0x370ksys_write+0x6c/0x100__arm64_sys_write+0x20/0x30invoke_syscall+0x4c/0x120el0_svc_common.constprop.0+0x44/0xf0do_el0_svc+0x24/0x38el0_svc+0x24/0x88el0t_64_sync_handler+0x134/0x150el0t_64_sync+0x14c/0x15

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39869 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: edma: Fix memory allocation size for queue_priority_mapFix a critical memory allocation bug in edma_setup_from_hw() wherequeue_priority_map was allocated with insufficient memory. The codedeclared queue_priority_map as s8 (*)[2] (pointer to array of 2 s8),but allocated memory using sizeof(s8) instead of the correct size.This caused out-of-bounds memory writes when accessing: queue_priority_map[i][0] = i; queue_priority_map[i][1] = i;The bug manifested as kernel crashes with "Oops - undefined instruction"on ARM platforms (BeagleBoard-X15) during EDMA driver probe, as thememory corruption triggered kernel hardening features on Clang.Change the allocation to use sizeof(*queue_priority_map) whichautomatically gets the correct size for the 2D array structure.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39870 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Fix double free in idxd_setup_wqs()The clean up in idxd_setup_wqs() has had a couple bugs because the errorhandling is a bit subtle. It's simpler to just re-write it in a cleanerway. The issues here are:1) If "idxd->max_wqs" is <= 0 then we call put_device(conf_dev) when "conf_dev" hasn't been initialized.2) If kzalloc_node() fails then again "conf_dev" is invalid. It's either uninitialized or it points to the "conf_dev" from the previous iteration so it leads to a double free.It's better to free partial loop iterations within the loop and thenthe unwinding at the end can handle whole loop iterations. I alsorenamed the labels to describe what the goto does and not where the gotowas located.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39871 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Remove improper idxd_freeThe call to idxd_free() introduces a duplicate put_device() leading to areference count underflow:refcount_t: underflow; use-after-free.WARNING: CPU: 15 PID: 4428 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110...Call Trace: idxd_remove+0xe4/0x120 [idxd] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x197/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x74/0xf0 pci_unregister_driver+0x2e/0xb0 idxd_exit_module+0x34/0x7a0 [idxd] __do_sys_delete_module.constprop.0+0x183/0x280 do_syscall_64+0x54/0xd70 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe idxd_unregister_devices() which is invoked at the very beginning ofidxd_remove(), already takes care of the necessary put_device() through thefollowing call path:idxd_unregister_devices() -> device_unregister() -> put_device()In addition, when CONFIG_DEBUG_KOBJECT_RELEASE is enabled, put_device() maytrigger asynchronous cleanup via schedule_delayed_work(). If idxd_free() iscalled immediately after, it can result in a use-after-free.Remove the improper idxd_free() to avoid both the refcount underflow andpotential memory corruption during module unload.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39873 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKBcan_put_echo_skb() takes ownership of the SKB and it may be freedduring or after the call.However, xilinx_can xcan_write_frame() keeps using SKB after the call.Fix that by only calling can_put_echo_skb() after the code is donetouching the SKB.The tx_lock is held for the entire xcan_write_frame() execution andalso on the can_get_echo_skb() side so the order of operations does notmatter.An earlier fix commit 3d3c817c3a40 ("can: xilinx_can: Fix usage of skbmemory") did not move the can_put_echo_skb() call far enough.[mkl: add "commit" in front of sha1 in patch description][mkl: fix indention]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39875 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:igb: Fix NULL pointer dereference in ethtool loopback testThe igb driver currently causes a NULL pointer dereference when executingthe ethtool loopback test. This occurs because there is no associatedq_vector for the test ring when it is set up, as interrupts are typicallynot added to the test rings.Since commit 5ef44b3cb43b removed the napi_id assignment in__xdp_rxq_info_reg(), there is no longer a need to pass a napi_id to it.Therefore, simply use 0 as the last parameter.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39876 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()The function of_phy_find_device may return NULL, so we need to takecare before dereferencing phy_dev.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39877 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs: fix use-after-free in state_show()state_show() reads kdamond->damon_ctx without holding damon_sysfs_lock. This allows a use-after-free race:CPU 0 CPU 1----- -----state_show() damon_sysfs_turn_damon_on()ctx = kdamond->damon_ctx; mutex_lock(&damon_sysfs_lock); damon_destroy_ctx(kdamond->damon_ctx); kdamond->damon_ctx = NULL; mutex_unlock(&damon_sysfs_lock);damon_is_running(ctx); /* ctx is freed */mutex_lock(&ctx->kdamond_lock); /* UAF */(The race can also occur with damon_sysfs_kdamonds_rm_dirs() anddamon_sysfs_kdamond_release(), which free or replace the context underdamon_sysfs_lock.)Fix by taking damon_sysfs_lock before dereferencing the context, mirroringthe locking used in pid_show().The bug has existed since state_show() first accessed kdamond->damon_ctx.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39880 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: fix invalid accesses to ceph_connection_v1_infoThere is a place where generic code in messenger.c is reading andanother place where it is writing to con->v1 union member withoutchecking that the union member is active (i.e. msgr1 is in use).On 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter,so such a read is almost guaranteed to return a bogus value instead of0 when msgr2 is in use. This ends up being fairly benign because theside effect is just the invalidation of the authorizer and successivefetching of new tickets.con->v1.connect_seq overlaps with con->v2.conn_bufs and the fact thatit's being written to can cause more serious consequences, but luckilyit's not something that happens often.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kernfs: Fix UAF in polling when open file is releasedA use-after-free (UAF) vulnerability was identified in the PSI (PressureStall Information) monitoring mechanism:BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140Read of size 8 at addr ffff3de3d50bd308 by task systemd/1psi_trigger_poll+0x3c/0x140cgroup_pressure_poll+0x70/0xa0cgroup_file_poll+0x8c/0x100kernfs_fop_poll+0x11c/0x1c0ep_item_poll.isra.0+0x188/0x2c0Allocated by task 1:cgroup_file_open+0x88/0x388kernfs_fop_open+0x73c/0xaf0do_dentry_open+0x5fc/0x1200vfs_open+0xa0/0x3f0do_open+0x7e8/0xd08path_openat+0x2fc/0x6b0do_filp_open+0x174/0x368Freed by task 8462:cgroup_file_release+0x130/0x1f8kernfs_drain_open_files+0x17c/0x440kernfs_drain+0x2dc/0x360kernfs_show+0x1b8/0x288cgroup_file_show+0x150/0x268cgroup_pressure_write+0x1dc/0x340cgroup_file_write+0x274/0x548Reproduction Steps:1. Open test/cpu.pressure and establish epoll monitoring2. Disable monitoring: echo 0 > test/cgroup.pressure3. Re-enable monitoring: echo 1 > test/cgroup.pressureThe race condition occurs because:1. When cgroup.pressure is disabled (echo 0 > cgroup.pressure), it: - Releases PSI triggers via cgroup_file_release() - Frees of->priv through kernfs_drain_open_files()2. While epoll still holds reference to the file and continues polling3. Re-enabling (echo 1 > cgroup.pressure) accesses freed of->privepolling disable/enable cgroup.pressurefd=open(cpu.pressure)while(1)...epoll_waitkernfs_fop_pollkernfs_get_active = true echo 0 > cgroup.pressure... cgroup_file_show kernfs_show // inactive kn kernfs_drain_open_files cft->release(of); kfree(ctx); ...kernfs_get_active = false echo 1 > cgroup.pressure kernfs_show kernfs_activate_one(kn);kernfs_fop_pollkernfs_get_active = truecgroup_file_pollpsi_trigger_poll// UAF...end: close(fd)To address this issue, introduce kernfs_get_active_of() for kernfs openfiles to obtain active references. This function will fail if the open filehas been released. Replace kernfs_get_active() with kernfs_get_active_of()to prevent further operations on released file descriptors.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39882 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: fix potential OF node use-after-freeThe for_each_child_of_node() helper drops the reference it takes to eachnode as it iterates over children and an explicit of_node_put() is onlyneeded when exiting the loop early.Drop the recently introduced bogus additional reference count decrementat each iteration that could potentially lead to a use-after-free.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39884 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix subvolume deletion lockup caused by inodes xarray raceThere is a race condition between inode eviction and inode caching thatcan cause a live struct btrfs_inode to be missing from the root->inodesxarray. Specifically, there is a window during evict() between the inodebeing unhashed and deleted from the xarray. If btrfs_iget() is calledfor the same inode in that window, it will be recreated and insertedinto the xarray, but then eviction will delete the new entry, leavingnothing in the xarray:Thread 1 Thread 2---------------------------------------------------------------evict() remove_inode_hash() btrfs_iget_path() btrfs_iget_locked() btrfs_read_locked_inode() btrfs_add_inode_to_root() destroy_inode() btrfs_destroy_inode() btrfs_del_inode_from_root() __xa_eraseIn turn, this can cause issues for subvolume deletion. Specifically, ifan inode is in this lost state, and all other inodes are evicted, thenbtrfs_del_inode_from_root() will call btrfs_add_dead_root() prematurely.If the lost inode has a delayed_node attached to it, then whenbtrfs_clean_one_deleted_snapshot() calls btrfs_kill_all_delayed_nodes(),it will loop forever because the delayed_nodes xarray will never becomeempty (unless memory pressure forces the inode out). We saw thismanifest as soft lockups in production.Fix it by only deleting the xarray entry if it matches the given inode(using __xa_cmpxchg()).

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39885 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix recursive semaphore deadlock in fiemap callsyzbot detected a OCFS2 hang due to a recursive semaphore on aFS_IOC_FIEMAP of the extent list on a specially crafted mmap file.context_switch kernel/sched/core.c:5357 [inline] __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961 __schedule_loop kernel/sched/core.c:7043 [inline] schedule+0x165/0x360 kernel/sched/core.c:7058 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115 rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185 __down_write_common kernel/locking/rwsem.c:1317 [inline] __down_write kernel/locking/rwsem.c:1326 [inline] down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591 ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142 do_page_mkwrite+0x14d/0x310 mm/memory.c:3361 wp_page_shared mm/memory.c:3762 [inline] do_wp_page+0x268d/0x5800 mm/memory.c:3981 handle_pte_fault mm/memory.c:6068 [inline] __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195 handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364 do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387 handle_page_fault arch/x86/mm/fault.c:1476 [inline] exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline]RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline]RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 a4 0f1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41RSP: 0018:ffffc9000403f950 EFLAGS: 00050256RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060 copy_to_user include/linux/uaccess.h:225 [inline] fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145 ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532 __do_sys_ioctl fs/ioctl.c:596 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584 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/0x7fRIP: 0033:0x7f5f13850fd9RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03bocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (sincev2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read theextent list of this running mmap executable. The user supplied buffer tohold the fiemap information page faults calling ocfs2_page_mkwrite() whichwill take a write lock (since v2.6.27-38-g00dc417fa3e7) of the samesemaphore. This recursive semaphore will hold filesystem locks and causesa hang of the fileystem.The ip_alloc_sem protects the inode extent list and size. Release theread semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap()and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlockon the last extent but simplifies the error path.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39895 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched: Fix sched_numa_find_nth_cpu() if mask offlinesched_numa_find_nth_cpu() uses a bsearch to look for the 'closest'CPU in sched_domains_numa_masks and given cpus mask. However theymight not intersect if all CPUs in the cpus mask are offline. bsearchwill return NULL in that case, bail out instead of dereferencing abogus pointer.The previous behaviour lead to this bug when using maxcpus=4 on anrk3399 (LLLLbb) (i.e. booting with all big CPUs offline):[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000[ 1.423635] Mem abort info:[ 1.423889] ESR = 0x0000000096000006[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits[ 1.424715] SET = 0, FnV = 0[ 1.424995] EA = 0, S1PTW = 0[ 1.425279] FSC = 0x06: level 2 translation fault[ 1.425735] Data abort info:[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP[ 1.429525] Modules linked in:[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488[ 1.432543] sp : ffffffc084e1b960[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68[ 1.439332] Call trace:[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)[ 1.440016] smp_call_function_any+0xc8/0xd0[ 1.440416] armv8_pmu_init+0x58/0x27c[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8[ 1.441603] armv8_pmu_device_probe+0x1c/0x28[ 1.442007] platform_probe+0x5c/0xac[ 1.442347] really_probe+0xbc/0x298[ 1.442683] __driver_probe_device+0x78/0x12c[ 1.443087] driver_probe_device+0xdc/0x160[ 1.443475] __driver_attach+0x94/0x19c[ 1.443833] bus_for_each_dev+0x74/0xd4[ 1.444190] driver_attach+0x24/0x30[ 1.444525] bus_add_driver+0xe4/0x208[ 1.444874] driver_register+0x60/0x128[ 1.445233] __platform_driver_register+0x24/0x30[ 1.445662] armv8_pmu_driver_init+0x28/0x4c[ 1.446059] do_one_initcall+0x44/0x25c[ 1.446416] kernel_init_freeable+0x1dc/0x3bc[ 1.446820] kernel_init+0x20/0x1d8[ 1.447151] ret_from_fork+0x10/0x20[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)[ 1.448040] ---[ end trace 0000000000000000 ]---[ 1.448483] note: swapper/0[1] exited with preempt_count 1[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b[ 1.449741] SMP: stopping secondary CPUs[ 1.450105] Kernel Offset: disabled[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b[ ---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTEWith CONFIG_HIGHPTE on 32-bit ARM, move_pages_pte() maps PTE pages usingkmap_local_page(), which requires unmapping in Last-In-First-Out order.The current code maps dst_pte first, then src_pte, but unmaps them in thesame order (dst_pte, src_pte), violating the LIFO requirement. Thiscauses the warning in kunmap_local_indexed(): WARNING: CPU: 0 PID: 604 at mm/highmem.c:622 kunmap_local_indexed+0x178/0x17c addr \!= __fix_to_virt(FIX_KMAP_BEGIN + idx)Fix this by reversing the unmap order to respect LIFO ordering.This issue follows the same pattern as similar fixes:- commit eca6828403b8 ("crypto: skcipher - fix mismatch between mapping and unmapping order")- commit 8cf57c6df818 ("nilfs2: eliminate staggered calls to kunmap in nilfs_rename")Both of which addressed the same fundamental requirement that kmap_localoperations must follow LIFO ordering.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39900 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: gen_estimator: fix est_timer() vs CONFIG_PREEMPT_RT=ysyzbot reported a WARNING in est_timer() [1]Problem here is that with CONFIG_PREEMPT_RT=y, timer callbackscan be preempted.Adopt preempt_disable_nested()/preempt_enable_nested() to fix this.[1] WARNING: CPU: 0 PID: 16 at ./include/linux/seqlock.h:221 __seqprop_assert include/linux/seqlock.h:221 [inline] WARNING: CPU: 0 PID: 16 at ./include/linux/seqlock.h:221 est_timer+0x6dc/0x9f0 net/core/gen_estimator.c:93Modules linked in:CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Not tainted syzkaller #0 PREEMPT_{RT,(full)}Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:__seqprop_assert include/linux/seqlock.h:221 [inline] RIP: 0010:est_timer+0x6dc/0x9f0 net/core/gen_estimator.c:93Call Trace: call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22c/0x710 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1043 smpboot_thread_fn+0x53f/0xa60 kernel/smpboot.c:160 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39902 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/slub: avoid accessing metadata when pointer is invalid in object_err()object_err() reports details of an object for further debugging, such asthe freelist pointer, redzone, etc. However, if the pointer is invalid,attempting to access object metadata can lead to a crash since it doesnot point to a valid object.One known path to the crash is when alloc_consistency_checks()determines the pointer to the allocated object is invalid because of afreelist corruption, and calls object_err() to report it. The debug codeshould report and handle the corruption gracefully and not crash in theprocess.In case the pointer is NULL or check_valid_pointer() returns false forthe pointer, only print the pointer value and skip accessing metadata.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39907 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC bufferAvoid below overlapping mappings by using a contiguousnon-cacheable buffer.[ 4.077708] DMA-API: stm32_fmc2_nfc 48810000.nand-controller: cacheline tracking EEXIST,overlapping mappings aren't supported[ 4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 add_dma_entry+0x23c/0x300[ 4.097071] Modules linked in:[ 4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1[ 4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT)[ 4.118824] Workqueue: events_unbound deferred_probe_work_func[ 4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 4.131624] pc : add_dma_entry+0x23c/0x300[ 4.135658] lr : add_dma_entry+0x23c/0x300[ 4.139792] sp : ffff800009dbb490[ 4.143016] x29: ffff800009dbb4a0 x28: 0000000004008022 x27: ffff8000098a6000[ 4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8[ 4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20[ 4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006[ 4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e[ 4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec[ 4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58[ 4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000[ 4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000[ 4.207128] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000812d2c40[ 4.214185] Call trace:[ 4.216605] add_dma_entry+0x23c/0x300[ 4.220338] debug_dma_map_sg+0x198/0x350[ 4.224373] __dma_map_sg_attrs+0xa0/0x110[ 4.228411] dma_map_sg_attrs+0x10/0x2c[ 4.232247] stm32_fmc2_nfc_xfer.isra.0+0x1c8/0x3fc[ 4.237088] stm32_fmc2_nfc_seq_read_page+0xc8/0x174[ 4.242127] nand_read_oob+0x1d4/0x8e0[ 4.245861] mtd_read_oob_std+0x58/0x84[ 4.249596] mtd_read_oob+0x90/0x150[ 4.253231] mtd_read+0x68/0xac

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39909 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters()Patch series "mm/damon: avoid divide-by-zero in DAMON module's parametersapplication".DAMON's RECLAIM and LRU_SORT modules perform no validation onuser-configured parameters during application, which may lead todivision-by-zero errors.Avoid the divide-by-zero by adding validation checks when DAMON modulesattempt to apply the parameters.This patch (of 2):During the calculation of 'hot_thres' and 'cold_thres', either'sample_interval' or 'aggr_interval' is used as the divisor, which maylead to division-by-zero errors. Fix it by directly returning -EINVALwhen such a case occurs. Additionally, since 'aggr_interval' is alreadyrequired to be set no smaller than 'sample_interval' in damon_set_attrs(),only the case where 'sample_interval' is zero needs to be checked.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39910 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()kasan_populate_vmalloc() and its helpers ignore the caller's gfp_mask andalways allocate memory using the hardcoded GFP_KERNEL flag. This makesthem inconsistent with vmalloc(), which was recently extended to supportGFP_NOFS and GFP_NOIO allocations.Page table allocations performed during shadow population also ignore theexternal gfp_mask. To preserve the intended semantics of GFP_NOFS andGFP_NOIO, wrap the apply_to_page_range() calls into the appropriatememalloc scope.xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.There was a report herehttps://lkml.kernel.org/r/686ea951.050a0220.385921.0016.GAE@google.comThis patch: - Extends kasan_populate_vmalloc() and helpers to take gfp_mask; - Passes gfp_mask down to alloc_pages_bulk() and __get_free_page(); - Enforces GFP_NOFS/NOIO semantics with memalloc_*_save()/restore() around apply_to_page_range(); - Updates vmalloc.c and percpu allocator call sites accordingly.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39911 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error pathIf request_irq() in i40e_vsi_request_irq_msix() fails in an iterationlater than the first, the error path wants to free the IRQs requestedso far. However, it uses the wrong dev_id argument for free_irq(), soit does not free the IRQs correctly and instead triggers the warning: Trying to free already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0 Modules linked in: i40e(+) [...] CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:__free_irq+0x192/0x2c0 [...] Call Trace: free_irq+0x32/0x70 i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e] i40e_vsi_request_irq+0x79/0x80 [i40e] i40e_vsi_open+0x21f/0x2f0 [i40e] i40e_open+0x63/0x130 [i40e] __dev_open+0xfc/0x210 __dev_change_flags+0x1fc/0x240 netif_change_flags+0x27/0x70 do_setlink.isra.0+0x341/0xc70 rtnl_newlink+0x468/0x860 rtnetlink_rcv_msg+0x375/0x450 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x288/0x3c0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x3a2/0x3d0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x82/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]---Use the same dev_id for free_irq() as for request_irq().I tested this with inserting code to fail intentionally.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39913 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.syzbot reported the splat below. [0]The repro does the following: 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes) 2. Attach the prog to a SOCKMAP 3. Add a socket to the SOCKMAP 4. Activate fault injection 5. Send data less than cork_bytesAt 5., the data is carried over to the next sendmsg() as it issmaller than the cork_bytes specified by bpf_msg_cork_bytes().Then, tcp_bpf_send_verdict() tries to allocate psock->cork to holdthe data, but this fails silently due to fault injection + __GFP_NOWARN.If the allocation fails, we need to revert the sk->sk_forward_allocchange done by sk_msg_alloc().Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocatepsock->cork.The "*copied" also needs to be updated such that a proper error canbe returned to the caller, sendmsg. It fails to allocate psock->cork.Nothing has been corked so far, so this patch simply sets "*copied"to 0.[0]:WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983Modules linked in:CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fcRSP: 0018:ffffc90000a08b48 EFLAGS: 00010246RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0Call Trace: __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39916 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters()When creating a new scheme of DAMON_RECLAIM, the calculation of'min_age_region' uses 'aggr_interval' as the divisor, which may lead todivision-by-zero errors. Fix it by directly returning -EINVAL when such acase occurs.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39925 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: j1939: implement NETDEV_UNREGISTER notification handlersyzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2problem, for j1939 protocol did not have NETDEV_UNREGISTER notificationhandler for undoing changes made by j1939_sk_bind().Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destructcallback") expects that a call to j1939_priv_put() can be unconditionallydelayed until j1939_sk_sock_destruct() is called. But we need to callj1939_priv_put() against an extra ref held by j1939_sk_bind() call(as a part of undoing changes made by j1939_sk_bind()) as soon asNETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct()is called via j1939_sk_release()). Otherwise, the extra ref on "structj1939_priv" held by j1939_sk_bind() call prevents "struct net_device" fromdropping the usage count to 1; making it impossible forunregister_netdevice() to continue.[mkl: remove space in front of label]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Set merge to zero early in af_alg_sendmsgIf an error causes af_alg_sendmsg to abort, ctx->merge may containa garbage value from the previous loop. This may then trigger acrash on the next entry into af_alg_sendmsg when it attempts to doa merge that can't be done.Fix this by setting ctx->merge to zero near the start of the loop.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39934 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm: bridge: anx7625: Fix NULL pointer dereference with early IRQIf the interrupt occurs before resource initialization is complete, theinterrupt handler/worker may access uninitialized data such as the I2Ctcpc_client device, potentially leading to NULL pointer dereference.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39937 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointerSince commit 7d5e9737efda ("net: rfkill: gpio: get the name and type fromdevice property") rfkill_find_type() gets called with the possiblyuninitialized "const char *type_name;" local variable.On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752"acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data;and there is no "type" property so device_property_read_string() will failand leave type_name uninitialized, leading to a potential crash.rfkill_find_type() does accept a NULL pointer, fix the potential crashby initializing type_name to NULL.Note likely sofar this has not been caught because:1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device2. The stack happened to contain NULL where type_name is stored

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39938 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failedIf earlier opening of source graph fails (e.g. ADSP rejects due toincorrect audioreach topology), the graph is closed and"dai_data->graph[dai->id]" is assigned NULL. Preparing the DAI for sinkgraph continues though and next call to q6apm_lpass_dai_prepare()receives dai_data->graph[dai->id]=NULL leading to NULL pointerexception: qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39944 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp()The original code relies on cancel_delayed_work() in otx2_ptp_destroy(),which does not ensure that the delayed work item synctstamp_work has fullycompleted if it was already running. This leads to use-after-free scenarioswhere otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_workremains active and attempts to dereference otx2_ptp in otx2_sync_tstamp().Furthermore, the synctstamp_work is cyclic, the likelihood of triggeringthe bug is nonnegligible.A typical race condition is illustrated below:CPU 0 (cleanup) | CPU 1 (delayed work callback)otx2_remove() | otx2_ptp_destroy() | otx2_sync_tstamp() cancel_delayed_work() | kfree(ptp) | | ptp = container_of(...); //UAF | ptp-> //UAFThis is confirmed by a KASAN report:BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0Write of size 8 at addr ffff88800aa09a18 by task bash/136...Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 otx2_ptp_init+0xb1/0x860 otx2_probe+0x4eb/0xc30 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30Freed by task 136: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 otx2_ptp_destroy+0x38/0x80 otx2_remove+0x10d/0x4c0 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f...Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled before the otx2_ptp isdeallocated.This bug was initially identified through static analysis. To reproduceand test it, I simulated the OcteonTX2 PCI device in QEMU and introducedartificial delays within the otx2_sync_tstamp() function to increase thelikelihood of triggering the bug.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39946 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tls: make sure to abort the stream if headers are bogusNormally we wait for the socket to buffer up the whole recordbefore we service it. If the socket has a tiny buffer, however,we read out the data sooner, to prevent connection stalls.Make sure that we abort the connection when we find out latethat the record is actually invalid. Retrying the parsing isfine in itself but since we copy some more data each timebefore we parse we can overflow the allocated skb space.Constructing a scenario in which we're under pressure withoutenough data in the socket to parse the length upfront is quitehard. syzbot figured out a way to do this by serving us the headerin small OOB sends, and then filling in the recvbuf with a largenormal send.Make sure that tls_rx_msg_size() aborts strp, if we reachan invalid record there's really no way to recover.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_syncThis fixes the following UFA in hci_acl_create_conn_sync where aconnection still pending is command submission (conn->state == BT_OPEN)maybe freed, also since this also can happen with the likes ofhci_le_create_conn_sync fix it as well:BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci3 hci_cmd_sync_workCall Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 Allocated by task 123736: 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] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 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+0x54b/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/0x7fFreed by task 103680: 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:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39984 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: tun: Update napi->skb after XDP processThe syzbot report a UAF issue: BUG: KASAN: slab-use-after-free in skb_reset_mac_header include/linux/skbuff.h:3150 [inline] BUG: KASAN: slab-use-after-free in napi_frags_skb net/core/gro.c:723 [inline] BUG: KASAN: slab-use-after-free in napi_gro_frags+0x6e/0x1030 net/core/gro.c:758 Read of size 8 at addr ffff88802ef22c18 by task syz.0.17/6079 CPU: 0 UID: 0 PID: 6079 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 skb_reset_mac_header include/linux/skbuff.h:3150 [inline] napi_frags_skb net/core/gro.c:723 [inline] napi_gro_frags+0x6e/0x1030 net/core/gro.c:758 tun_get_user+0x28cb/0x3e20 drivers/net/tun.c:1920 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 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 Allocated by task 6079: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:330 [inline] __kasan_mempool_unpoison_object+0xa0/0x170 mm/kasan/common.c:558 kasan_mempool_unpoison_object include/linux/kasan.h:388 [inline] napi_skb_cache_get+0x37b/0x6d0 net/core/skbuff.c:295 __alloc_skb+0x11e/0x2d0 net/core/skbuff.c:657 napi_alloc_skb+0x84/0x7d0 net/core/skbuff.c:811 napi_get_frags+0x69/0x140 net/core/gro.c:673 tun_napi_alloc_frags drivers/net/tun.c:1404 [inline] tun_get_user+0x77c/0x3e20 drivers/net/tun.c:1784 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 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 6079: 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:243 [inline] __kasan_slab_free+0x5b/0x80 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2422 [inline] slab_free mm/slub.c:4695 [inline] kmem_cache_free+0x18f/0x400 mm/slub.c:4797 skb_pp_cow_data+0xdd8/0x13e0 net/core/skbuff.c:969 netif_skb_check_for_xdp net/core/dev.c:5390 [inline] netif_receive_generic_xdp net/core/dev.c:5431 [inline] do_xdp_generic+0x699/0x11a0 net/core/dev.c:5499 tun_get_user+0x2523/0x3e20 drivers/net/tun.c:1872 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 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/0x7fAfter commit e6d5dbdd20aa ("xdp: add multi-buff support for xdp running ingeneric mode"), the original skb may be freed in skb_pp_cow_data() whenXDP program was attached, which was allocated in tun_napi_alloc_frags().However, the napi->skb still point to the original skb, update it afterXDP process.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39985 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflowSending an PF_PACKET allows to bypass the CAN framework logic and todirectly reach the xmit() function of a CAN driver. The only checkwhich is performed by the PF_PACKET framework is to make sure thatskb->len fits the interface's MTU.Unfortunately, because the mcba_usb driver does not populate itsnet_device_ops->ndo_change_mtu(), it is possible for an attacker toconfigure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999After doing so, the attacker could open a PF_PACKET socket using theETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, };The CAN drivers' xmit() function are calling can_dev_dropped_skb() tocheck that the skb is valid, unfortunately under above conditions, themalicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length.And so, mcba_usb_start_xmit() receives a CAN XL frame which it is notable to correctly handle and will thus misinterpret it as a CAN frame.This can result in a buffer overflow. The driver will consume cf->lenas-is with no further checks on these lines: usb_msg.dlc = cf->len; memcpy(usb_msg.data, cf->data, usb_msg.dlc);Here, cf->len corresponds to the flags field of the CAN XL frame. Inour previous example, we set canxl_frame->flags to 0xff. Because themaximum expected length is 8, a buffer overflow of 247 bytes occurs!Populate net_device_ops->ndo_change_mtu() to ensure that theinterface's MTU can not be set to anything bigger than CAN_MTU. Byfixing the root cause, this prevents the buffer overflow.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39986 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflowSending an PF_PACKET allows to bypass the CAN framework logic and todirectly reach the xmit() function of a CAN driver. The only checkwhich is performed by the PF_PACKET framework is to make sure thatskb->len fits the interface's MTU.Unfortunately, because the sun4i_can driver does not populate itsnet_device_ops->ndo_change_mtu(), it is possible for an attacker toconfigure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999After doing so, the attacker could open a PF_PACKET socket using theETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, };The CAN drivers' xmit() function are calling can_dev_dropped_skb() tocheck that the skb is valid, unfortunately under above conditions, themalicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length.And so, sun4ican_start_xmit() receives a CAN XL frame which it is notable to correctly handle and will thus misinterpret it as a CAN frame.This can result in a buffer overflow. The driver will consume cf->lenas-is with no further checks on this line: dlc = cf->len;Here, cf->len corresponds to the flags field of the CAN XL frame. Inour previous example, we set canxl_frame->flags to 0xff. Because themaximum expected length is 8, a buffer overflow of 247 bytes occurs acouple line below when doing: for (i = 0; i < dlc; i++) writel(cf->data[i], priv->base + (dreg + i * 4));Populate net_device_ops->ndo_change_mtu() to ensure that theinterface's MTU can not be set to anything bigger than CAN_MTU. Byfixing the root cause, this prevents the buffer overflow.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39987 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: hi311x: populate ndo_change_mtu() to prevent buffer overflowSending an PF_PACKET allows to bypass the CAN framework logic and todirectly reach the xmit() function of a CAN driver. The only checkwhich is performed by the PF_PACKET framework is to make sure thatskb->len fits the interface's MTU.Unfortunately, because the sun4i_can driver does not populate itsnet_device_ops->ndo_change_mtu(), it is possible for an attacker toconfigure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999After doing so, the attacker could open a PF_PACKET socket using theETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, };The CAN drivers' xmit() function are calling can_dev_dropped_skb() tocheck that the skb is valid, unfortunately under above conditions, themalicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length.And so, hi3110_hard_start_xmit() receives a CAN XL frame which it isnot able to correctly handle and will thus misinterpret it as a CANframe. The driver will consume frame->len as-is with no furtherchecks.This can result in a buffer overflow later on in hi3110_hw_tx() onthis line: memcpy(buf + HI3110_FIFO_EXT_DATA_OFF, frame->data, frame->len);Here, frame->len corresponds to the flags field of the CAN XL frame.In our previous example, we set canxl_frame->flags to 0xff. Becausethe maximum expected length is 8, a buffer overflow of 247 bytesoccurs!Populate net_device_ops->ndo_change_mtu() to ensure that theinterface's MTU can not be set to anything bigger than CAN_MTU. Byfixing the root cause, this prevents the buffer overflow.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39988 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflowSending an PF_PACKET allows to bypass the CAN framework logic and todirectly reach the xmit() function of a CAN driver. The only checkwhich is performed by the PF_PACKET framework is to make sure thatskb->len fits the interface's MTU.Unfortunately, because the etas_es58x driver does not populate itsnet_device_ops->ndo_change_mtu(), it is possible for an attacker toconfigure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999After doing so, the attacker could open a PF_PACKET socket using theETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, };The CAN drivers' xmit() function are calling can_dev_dropped_skb() tocheck that the skb is valid, unfortunately under above conditions, themalicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length.And so, es58x_start_xmit() receives a CAN XL frame which it is notable to correctly handle and will thus misinterpret it as a CAN(FD)frame.This can result in a buffer overflow. For example, using the es581.4variant, the frame will be dispatched to es581_4_tx_can_msg(), gothrough the last check at the beginning of this function: if (can_is_canfd_skb(skb)) return -EMSGSIZE;and reach this line: memcpy(tx_can_msg->data, cf->data, cf->len);Here, cf->len corresponds to the flags field of the CAN XL frame. Inour previous example, we set canxl_frame->flags to 0xff. Because themaximum expected length is 8, a buffer overflow of 247 bytes occurs!Populate net_device_ops->ndo_change_mtu() to ensure that theinterface's MTU can not be set to anything bigger than CAN_MTU orCANFD_MTU (depending on the device capabilities). By fixing the rootcause, this prevents the buffer overflow.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39990 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check the helper function is valid in get_helper_protokernel test robot reported verifier bug [1] where the helper funcpointer could be NULL due to disabled config option.As Alexei suggested we could check on that in get_helper_protodirectly. Marking tail_call helper func with BPF_PTR_POISON,because it is unused by design. [1] https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39991 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load()If ab->fw.m3_data points to data, then fw pointer remains null.Further, if m3_mem is not allocated, then fw is dereferenced to bepassed to ath11k_err function.Replace fw->size by m3_len.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39992 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: swap: check for stable address space before operating on the VMAIt is possible to hit a zero entry while traversing the vmas in unuse_mm()called from swapoff path and accessing it causes the OOPS:Unable to handle kernel NULL pointer dereference at virtual address0000000000000446--> Loading the memory from offset 0x40 on theXA_ZERO_ENTRY as address.Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation faultThe issue is manifested from the below race between the fork() on aprocess and swapoff:fork(dup_mmap()) swapoff(unuse_mm)--------------- -----------------1) Identical mtree is built using __mt_dup().2) copy_pte_range()--> copy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation.3) Fatal signal is sent to the parentprocess(which is the current during thefork) thus skip the duplication of thevmas and mark the vma range withXA_ZERO_ENTRY as a marker for this processthat helps during exit_mmap(). 4) swapoff is tried on the 'mm' added to the 'mmlist' as part of the 2. 5) unuse_mm(), that iterates through the vma's of this 'mm' will hit the non-NULL zero entry and operating on this zero entry as a vma is resulting into the oops.The proper fix would be around not exposing this partially-valid tree toothers when droping the mmap lock, which is being solved with [1]. Asimpler solution would be checking for MMF_UNSTABLE, as it is set ifmm_struct is not fully initialized in dup_mmap().Thanks to Liam/Lorenzo/David for all the suggestions in fixing thisissue.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39993 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: rc: fix races with imon_disconnect()Syzbot reports a KASAN issue as below:BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline]BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline]dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106print_address_description mm/kasan/report.c:317 [inline]print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433kasan_report+0xb1/0x1e0 mm/kasan/report.c:495__create_pipe include/linux/usb.h:1945 [inline]send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991vfs_write+0x2d7/0xdd0 fs/read_write.c:576ksys_write+0x127/0x250 fs/read_write.c:631do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdThe iMON driver improperly releases the usb_device reference inimon_disconnect without coordinating with active users of thedevice.Specifically, the fields usbdev_intf0 and usbdev_intf1 are notprotected by the users counter (ictx->users). During probe,imon_init_intf0 or imon_init_intf1 increments the usb_devicereference count depending on the interface. However, duringdisconnect, usb_put_dev is called unconditionally, regardless ofactual usage.As a result, if vfd_write or other operations are still inprogress after disconnect, this can lead to a use-after-free ofthe usb_device pointer.Thread 1 vfd_write Thread 2 imon_disconnect ... if usb_put_dev(ictx->usbdev_intf0) else usb_put_dev(ictx->usbdev_intf1)...while send_packet if pipe = usb_sndintpipe( ictx->usbdev_intf0) UAF else pipe = usb_sndctrlpipe( ictx->usbdev_intf0, 0) UAFGuard access to usbdev_intf0 and usbdev_intf1 after disconnect bychecking ictx->disconnected in all writer paths. Add early returnwith -ENODEV in send_packet(), vfd_write(), lcd_write() anddisplay_open() if the device is no longer present.Set and read ictx->disconnected under ictx->lock to ensure memorysynchronization. Acquire the lock in imon_disconnect() before settingthe flag to synchronize with any ongoing operations.Ensure writers exit early and safely after disconnect before the USBcore proceeds with cleanup.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39994 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: tuner: xc5000: Fix use-after-free in xc5000_releaseThe original code uses cancel_delayed_work() in xc5000_release(), whichdoes not guarantee that the delayed work item timer_sleep has fullycompleted if it was already running. This leads to use-after-free scenarioswhere xc5000_release() may free the xc5000_priv while timer_sleep is stillactive and attempts to dereference the xc5000_priv.A typical race condition is illustrated below:CPU 0 (release thread) | CPU 1 (delayed work callback)xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAFReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the timer_sleep is properly canceled before the xc5000_priv memoryis deallocated.A deadlock concern was considered: xc5000_release() is called in a processcontext and is not holding any locks that the timer_sleep work item mightalso need. Therefore, the use of the _sync() variant is safe here.This bug was initially identified through static analysis.[hverkuil: fix typo in Subject: tunner -> tuner]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39995 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: tc358743: Fix use-after-free bugs caused by orphan timer in probeThe state->timer is a cyclic timer that schedules work_i2c_poll anddelayed_work_enable_hotplug, while rearming itself. Using timer_delete()fails to guarantee the timer isn't still running when destroyed, similarlycancel_delayed_work() cannot ensure delayed_work_enable_hotplug hasterminated if already executing. During probe failure after timerinitialization, these may continue running as orphans and reference thealready-freed tc358743_state object through tc358743_irq_poll_timer.The following is the trace captured by KASAN.BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0Write of size 8 at addr ffff88800ded83c8 by task swapper/1/0...Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __pfx_sched_balance_find_src_group+0x10/0x10 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? tmigr_update_events+0x280/0x740 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x98/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...Allocated by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_node_track_caller_noprof+0x198/0x430 devm_kmalloc+0x7b/0x1e0 tc358743_probe+0xb7/0x610 i2c_device_probe+0x51d/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 release_nodes+0xa4/0x100 devres_release_group+0x1b2/0x380 i2c_device_probe+0x694/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f...Replace timer_delete() with timer_delete_sync() and cancel_delayed_work()with cancel_delayed_work_sync() to ensure proper termination of timer andwork items before resource cleanup.This bug was initially identified through static analysis. For reproductionand testing, I created a functional emulation of the tc358743 device via akernel module and introduced faults through the debugfs interface.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39996 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_removeThe original code uses cancel_delayed_work() in flexcop_pci_remove(), whichdoes not guarantee that the delayed work item irq_check_work has fullycompleted if it was already running. This leads to use-after-free scenarioswhere flexcop_pci_remove() may free the flexcop_device while irq_check_workis still active and attempts to dereference the device.A typical race condition is illustrated below:CPU 0 (remove) | CPU 1 (delayed work callback)flexcop_pci_remove() | flexcop_pci_irq_check_work() cancel_delayed_work() | flexcop_device_kfree(fc_pci->fc_dev) | | fc = fc_pci->fc_dev; // UAFThis is confirmed by a KASAN report:==================================================================BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0Write of size 8 at addr ffff8880093aa8c8 by task bash/135...Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x1be/0x460 flexcop_device_kmalloc+0x54/0xe0 flexcop_pci_probe+0x1f/0x9d0 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30Freed by task 135: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 flexcop_device_kfree+0x32/0x50 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f...Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled and any executing delayedwork has finished before the device memory is deallocated.This bug was initially identified through static analysis. To reproduceand test it, I simulated the B2C2 FlexCop PCI device in QEMU and introducedartificial delays within the flexcop_pci_irq_check_work() function toincrease the likelihood of triggering the bug.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39997 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_freeThe previous commit 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly atremoval") patched a UAF issue caused by the error timer.However, because the error timer kill added in this patch occurs after theendpoint delete, a race condition to UAF still occurs, albeit rarely.Additionally, since kill-cleanup for urb is also missing, freed memory canbe accessed in interrupt context related to urb, which can cause UAF.Therefore, to prevent this, error timer and urb must be killed beforefreeing the heap memory.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40000 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries toaccess already freed skb_data: BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] Use-after-free write at 0x0000000020309d9d (in kfence-#251): rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago): __alloc_skb net/core/skbuff.c:659 __netdev_alloc_skb net/core/skbuff.c:734 ieee80211_nullfunc_get net/mac80211/tx.c:5844 rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago): ieee80211_tx_status_skb net/mac80211/status.c:1117 rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564 rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651 rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676 rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238 __napi_poll net/core/dev.c:7495 net_rx_action net/core/dev.c:7557 net/core/dev.c:7684 handle_softirqs kernel/softirq.c:580 do_softirq.part.0 kernel/softirq.c:480 __local_bh_enable_ip kernel/softirq.c:407 rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927 irq_thread_fn kernel/irq/manage.c:1133 irq_thread kernel/irq/manage.c:1257 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258It is a consequence of a race between the waiting and the signaling sideof the completion: Waiting thread Completing threadrtw89_core_tx_kick_off_and_wait() rcu_assign_pointer(skb_data->wait, wait) /* start waiting */ wait_for_completion_timeout() rtw89_pci_tx_status() rtw89_core_tx_wait_complete() rcu_read_lock() /* signals completion and ---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40009 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs/proc/task_mmu: check p->vec_buf for NULLWhen the PAGEMAP_SCAN ioctl is invoked with vec_len = 0 reachespagemap_scan_backout_range(), kernel panics with null-ptr-deref:[ 44.936808] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI[ 44.937797] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007][ 44.938391] CPU: 1 UID: 0 PID: 2480 Comm: reproducer Not tainted 6.17.0-rc6 #22 PREEMPT(none)[ 44.939062] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 44.939935] RIP: 0010:pagemap_scan_thp_entry.isra.0+0x741/0xa80[ 44.946828] Call Trace:[ 44.947030] [ 44.949219] pagemap_scan_pmd_entry+0xec/0xfa0[ 44.952593] walk_pmd_range.isra.0+0x302/0x910[ 44.954069] walk_pud_range.isra.0+0x419/0x790[ 44.954427] walk_p4d_range+0x41e/0x620[ 44.954743] walk_pgd_range+0x31e/0x630[ 44.955057] __walk_page_range+0x160/0x670[ 44.956883] walk_page_range_mm+0x408/0x980[ 44.958677] walk_page_range+0x66/0x90[ 44.958984] do_pagemap_scan+0x28d/0x9c0[ 44.961833] do_pagemap_cmd+0x59/0x80[ 44.962484] __x64_sys_ioctl+0x18d/0x210[ 44.962804] do_syscall_64+0x5b/0x290[ 44.963111] entry_SYSCALL_64_after_hwframe+0x76/0x7evec_len = 0 in pagemap_scan_init_bounce_buffer() means no buffers areallocated and p->vec_buf remains set to NULL.This breaks an assumption made later in pagemap_scan_backout_range(), thatpage_region is always allocated for p->vec_buf_index.Fix it by explicitly checking p->vec_buf for NULL before dereferencing.Other sites that might run into same deref-issue are already (directly ortransitively) protected by checking p->vec_buf.Note:From PAGEMAP_SCAN man page, it seems vec_len = 0 is valid when no outputis requested and it's only the side effects caller is interested in,hence it passes check in pagemap_scan_get_args().This issue was found by syzkaller.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40011 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/gma500: Fix null dereference in hdmi teardownpci_set_drvdata sets the value of pdev->driver_data to NULL,after which the driver_data obtained from the same dev isdereferenced in oaktrail_hdmi_i2c_exit, and the i2c_dev isextracted from it. To prevent this, swap these calls.Found by Linux Verification Center (linuxtesting.org) with Svacer.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: audioreach: fix potential null pointer dereferenceIt is possible that the topology parsing functionaudioreach_widget_load_module_common() could return NULL or an errorpointer. Add missing NULL check so that we do not dereference it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40024 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vhost: Take a reference on the task in struct vhost_task.vhost_task_create() creates a task and keeps a reference to itstask_struct. That task may exit early via a signal and its task_structwill be released.A pending vhost_task_wake() will then attempt to wake the task andaccess a task_struct which is no longer there.Acquire a reference on the task_struct while creating the thread andrelease the reference while the struct vhost_task itself is removed.If the task exits early due to a signal, then the vhost_task_wake() willstill access a valid task_struct. The wake is safe and will be skippedin this case.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40029 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: Check return value of platform_get_resource()platform_get_resource() returns NULL in case of failure, so check itsreturn value and propagate the error in order to prevent NULL pointerdereference.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40031 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tee: fix register_shm_helper()In register_shm_helper(), fix incorrect error handling for a call toiov_iter_extract_pages(). A case is missing for wheniov_iter_extract_pages() only got some pages and return a number largerthan 0, but not the requested amount.This fixes a possible NULL pointer dereference following a bad input fromioctl(TEE_IOC_SHM_REGISTER) where parts of the buffer isn't mapped.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40033 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: pru: Fix potential NULL pointer dereference in pru_rproc_set_ctable()pru_rproc_set_ctable() accessed rproc->priv before the IS_ERR_OR_NULLcheck, which could lead to a null pointer dereference. Move the pruassignment, ensuring we never dereference a NULL rproc pointer.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40035 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leakStruct ff_effect_compat is embedded twice insideuinput_ff_upload_compat, contains internal padding. In particular, thereis a hole after struct ff_replay to satisfy alignment requirements forthe following union member. Without clearing the structure,copy_to_user() may leak stack data to userspace.Initialize ff_up_compat to zero before filling valid fields.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40036 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:misc: fastrpc: fix possible map leak in fastrpc_put_argscopy_to_user() failure would cause an early return without cleaning upthe fdlist, which has been updated by the DSP. This could lead to mapleak. Fix this by redirecting to a cleanup path on failure, ensuringthat all mapped buffers are properly released before returning.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40037 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: simplefb: Fix use after free in simplefb_detach_genpds()The pm_domain cleanup can not be devres managed as it uses structsimplefb_par which is allocated within struct fb_info byframebuffer_alloc(). This allocation is explicitly freed byunregister_framebuffer() in simplefb_remove().Devres managed cleanup runs after the device remove call and thus can nolonger access struct simplefb_par.Call simplefb_detach_genpds() explicitly from simplefb_destroy() likethe cleanup functions for clocks and regulators.Fixes an use after free on M2 Mac mini duringaperture_remove_conflicting_devices() using the downstream asahi kernelwith Debian's kernel config. For unknown reasons this started toconsistently dereference an invalid pointer in v6.16.3 based kernels.[ 6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220[ 6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227[ 6.750697][ 6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S 6.16.3-asahi+ #16 PREEMPTLAZY[ 6.752186] Tainted: [S]=CPU_OUT_OF_SPEC[ 6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT)[ 6.752189] Call trace:[ 6.752190] show_stack+0x34/0x98 (C)[ 6.752194] dump_stack_lvl+0x60/0x80[ 6.752197] print_report+0x17c/0x4d8[ 6.752201] kasan_report+0xb4/0x100[ 6.752206] __asan_report_load4_noabort+0x20/0x30[ 6.752209] simplefb_detach_genpds+0x58/0x220[ 6.752213] devm_action_release+0x50/0x98[ 6.752216] release_nodes+0xd0/0x2c8[ 6.752219] devres_release_all+0xfc/0x178[ 6.752221] device_unbind_cleanup+0x28/0x168[ 6.752224] device_release_driver_internal+0x34c/0x470[ 6.752228] device_release_driver+0x20/0x38[ 6.752231] bus_remove_device+0x1b0/0x380[ 6.752234] device_del+0x314/0x820[ 6.752238] platform_device_del+0x3c/0x1e8[ 6.752242] platform_device_unregister+0x20/0x50[ 6.752246] aperture_detach_platform_device+0x1c/0x30[ 6.752250] aperture_detach_devices+0x16c/0x290[ 6.752253] aperture_remove_conflicting_devices+0x34/0x50...[ 6.752343][ 6.967409] Allocated by task 62:[ 6.970724] kasan_save_stack+0x3c/0x70[ 6.974560] kasan_save_track+0x20/0x40[ 6.978397] kasan_save_alloc_info+0x40/0x58[ 6.982670] __kasan_kmalloc+0xd4/0xd8[ 6.986420] __kmalloc_noprof+0x194/0x540[ 6.990432] framebuffer_alloc+0xc8/0x130[ 6.994444] simplefb_probe+0x258/0x2378...[ 7.054356][ 7.055838] Freed by task 227:[ 7.058891] kasan_save_stack+0x3c/0x70[ 7.062727] kasan_save_track+0x20/0x40[ 7.066565] kasan_save_free_info+0x4c/0x80[ 7.070751] __kasan_slab_free+0x6c/0xa0[ 7.074675] kfree+0x10c/0x380[ 7.077727] framebuffer_release+0x5c/0x90[ 7.081826] simplefb_destroy+0x1b4/0x2c0[ 7.085837] put_fb_info+0x98/0x100[ 7.089326] unregister_framebuffer+0x178/0x320[ 7.093861] simplefb_remove+0x3c/0x60[ 7.097611] platform_remove+0x60/0x98[ 7.101361] device_remove+0xb8/0x160[ 7.105024] device_release_driver_internal+0x2fc/0x470[ 7.110256] device_release_driver+0x20/0x38[ 7.114529] bus_remove_device+0x1b0/0x380[ 7.118628] device_del+0x314/0x820[ 7.122116] platform_device_del+0x3c/0x1e8[ 7.126302] platform_device_unregister+0x20/0x50[ 7.131012] aperture_detach_platform_device+0x1c/0x30[ 7.136157] aperture_detach_devices+0x16c/0x290[ 7.140779] aperture_remove_conflicting_devices+0x34/0x50...

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40038 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't validSkip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIPisn't valid, e.g. because KVM is running with nrips=false. SVM mustdecode and emulate to skip the instruction if the CPU doesn't provide thenext RIP, and getting the instruction bytes to decode requires readingguest memory. Reading guest memory through the emulator can fault, i.e.can sleep, which is disallowed since the fastpath handlers run with IRQsdisabled. BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 30580 hardirqs last enabled at (30579): [] vcpu_run+0x1787/0x1db0 [kvm] hardirqs last disabled at (30580): [] __schedule+0x1e2/0xed0 softirqs last enabled at (30570): [] fpu_swap_kvm_fpstate+0x44/0x210 softirqs last disabled at (30568): [] fpu_swap_kvm_fpstate+0x44/0x210 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE Tainted: [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025 Call Trace: dump_stack_lvl+0x7d/0xb0 __might_resched+0x271/0x290 __might_fault+0x28/0x80 kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm] kvm_fetch_guest_virt+0x92/0xc0 [kvm] __do_insn_fetch_bytes+0xf3/0x1e0 [kvm] x86_decode_insn+0xd1/0x1010 [kvm] x86_emulate_instruction+0x105/0x810 [kvm] __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd] handle_fastpath_invd+0xc4/0x1a0 [kvm] vcpu_run+0x11a1/0x1db0 [kvm] kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm] kvm_vcpu_ioctl+0x578/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x8a/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f479d57a94b Note, this is essentially a reapply of commit 5c30e8101e8d ("KVM: SVM:Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"), but withdifferent justification (KVM now grabs SRCU when skipping the instructionfor other reasons).

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40040 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/ksm: fix flag-dropping behavior in ksm_madvisesyzkaller discovered the following crash: (kernel BUG)[ 44.607039] ------------[ cut here ]------------[ 44.607422] kernel BUG at mm/userfaultfd.c:2067![ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460[ 44.617726] Call Trace:[ 44.617926] [ 44.619284] userfaultfd_release+0xef/0x1b0[ 44.620976] __fput+0x3f9/0xb60[ 44.621240] fput_close_sync+0x110/0x210[ 44.622222] __x64_sys_close+0x8f/0x120[ 44.622530] do_syscall_64+0x5b/0x2f0[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 44.623244] RIP: 0033:0x7f365bb3f227Kernel panics because it detects UFFD inconsistency duringuserfaultfd_release_all(). Specifically, a VMA which has a valid pointerto vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.The inconsistency is caused in ksm_madvise(): when user calls madvise()with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,it accidentally clears all flags stored in the upper 32 bits ofvma->vm_flags.Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int andint are 32-bit wide. This setup causes the following mishap during the &=~VM_MERGEABLE assignment.VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is thenpromoted to unsigned long before the & operation. This promotion fillsupper 32 bits with leading 0s, as we're doing unsigned conversion (andeven for a signed conversion, this wouldn't help as the leading bit is 0).& operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffffinstead of intended 0xffff'ffff'7fff'ffff and hence accidentally clearsthe upper 32-bits of its value.Fix it by changing `VM_MERGEABLE` constant to unsigned long, using theBIT() macro.Note: other VM_* flags are not affected: This only happens to theVM_MERGEABLE flag, as the other VM_* flags are all constants of type intand after ~ operation, they end up with leading 1 and are thus convertedto unsigned long with leading 1s.Note 2:After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this isno longer a kernel BUG, but a WARNING at the same place:[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067but the root-cause (flag-drop) remains the same.[akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40042 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix race condition in kprobe initialization causing NULL pointer dereferenceThere is a critical race condition in kprobe initialization that can lead toNULL pointer dereference and kernel crash.[1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000...[1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO)[1135630.269239] pc : kprobe_perf_func+0x30/0x260[1135630.277643] lr : kprobe_dispatcher+0x44/0x60[1135630.286041] sp : ffffaeff4977fa40[1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400[1135630.302837] x27: 0000000000000000 x26: 0000000000000000[1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528[1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50[1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50[1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000[1135630.349985] x17: 0000000000000000 x16: 0000000000000000[1135630.359285] x15: 0000000000000000 x14: 0000000000000000[1135630.368445] x13: 0000000000000000 x12: 0000000000000000[1135630.377473] x11: 0000000000000000 x10: 0000000000000000[1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000[1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000[1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000[1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006[1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000[1135630.429410] Call trace:[1135630.434828] kprobe_perf_func+0x30/0x260[1135630.441661] kprobe_dispatcher+0x44/0x60[1135630.448396] aggr_pre_handler+0x70/0xc8[1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0[1135630.462435] brk_handler+0xbc/0xd8[1135630.468437] do_debug_exception+0x84/0x138[1135630.475074] el1_dbg+0x18/0x8c[1135630.480582] security_file_permission+0x0/0xd0[1135630.487426] vfs_write+0x70/0x1c0[1135630.493059] ksys_write+0x5c/0xc8[1135630.498638] __arm64_sys_write+0x24/0x30[1135630.504821] el0_svc_common+0x78/0x130[1135630.510838] el0_svc_handler+0x38/0x78[1135630.516834] el0_svc+0x8/0x1b0kernel/trace/trace_kprobe.c: 13080xffff3df8995039ec : ldr x21, [x24,#120]include/linux/compiler.h: 2940xffff3df8995039f0 : ldr x1, [x21,x0]kernel/trace/trace_kprobe.c1308: head = this_cpu_ptr(call->perf_events);1309: if (hlist_empty(head))1310: return 0;crash> struct trace_event_call -ostruct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ...}crash> struct trace_event_call ffffaf015340e528struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ...}Race Condition Analysis:The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)<- KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL)Problem:1. CPU0 executes (1) assigning tp_event->perf_events = list2. CPU0 executes (2) enabling kprobe functionality via class->reg()3. CPU1 triggers and reaches kprobe_dispatcher4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed)5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULLCPU1 sees that kprobe functionality is enabled but does not see thatperf_events has been assigned.Add pairing read an---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40048 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Let userspace take care of interrupt maskRemove the logic to set interrupt mask by default in uio_hv_genericdriver as the interrupt mask value is supposed to be controlledcompletely by the user space. If the mask bit gets changedby the driver, concurrently with user mode operating on the ring,the mask bit may be set when it is supposed to be clear, and theuser-mode driver will miss an interrupt which will cause a hang.For eg- when the driver sets inbound ring buffer interrupt mask to 1,the host does not interrupt the guest on the UIO VMBus channel.However, setting the mask does not prevent the host from putting amessage in the inbound ring buffer. So let's assume that happens,the host puts a message into the ring buffer but does not interrupt.Subsequently, the user space code in the guest sets the inbound ringbuffer interrupt mask to 0, saying "Hey, I'm ready for interrupts".User space code then calls pread() to wait for an interrupt.Then one of two things happens:* The host never sends another message. So the pread() waits forever.* The host does send another message. But because there's already a message in the ring buffer, it doesn't generate an interrupt. This is the correct behavior, because the host should only send an interrupt when the inbound ring buffer transitions from empty to not-empty. Adding an additional message to a ring buffer that is not empty is not supposed to generate an interrupt on the guest. Since the guest is waiting in pread() and not removing messages from the ring buffer, the pread() waits forever.This could be easily reproduced in hv_fcopy_uio_daemon if we delaysetting interrupt mask to 0.Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,there's a race condition. Once user space empties the inbound ringbuffer, but before user space sets interrupt_mask to 0, the host couldput another message in the ring buffer but it wouldn't interrupt.Then the next pread() would hang.Fix these by removing all instances where interrupt_mask is changed,while keeping the one in set_event() unchanged to enable userspacecontrol the interrupt mask by writing 0/1 to /dev/uioX.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40051 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vhost: vringh: Modify the return value checkThe return value of copy_from_iter and copy_to_iter can't be negative,check whether the copied lengths are equal.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40052 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix crypto buffers in non-linear memoryThe crypto API, through the scatterlist API, expects input buffers to bein linear memory. We handle this with the cifs_sg_set_buf() helperthat converts vmalloc'd memory to their corresponding pages.However, when we allocate our aead_request buffer (@creq insmb2ops.c::crypt_message()), we do so with kvzalloc(), which possiblyputs aead_request->__ctx in vmalloc area.AEAD algorithm then uses ->__ctx for its private/internal data andoperations, and uses sg_set_buf() for such data on a few places.This works fine as long as @creq falls into kmalloc zone (smallrequests) or vmalloc'd memory is still within linear range.Tasks' stacks are vmalloc'd by default (CONFIG_VMAP_STACK=y), so toomany tasks will increment the base stacks' addresses to a point wherevirt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when thathappens.In practice: too many parallel reads and writes on an encrypted mountwill trigger this bug.To fix this, always alloc @creq with kmalloc() instead.Also drop the @sensitive_size variable/arguments sincekfree_sensitive() doesn't need it.Backtrace:[ 945.272081] ------------[ cut here ]------------[ 945.272774] kernel BUG at include/linux/scatterlist.h:209![ 945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI[ 945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary)[ 945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014[ 945.276877] Workqueue: writeback wb_workfn (flush-cifs-2)[ 945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220[ 945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b[ 945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246[ 945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030[ 945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070[ 945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000[ 945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070[ 945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010[ 945.284407] FS: 0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000[ 945.285262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0[ 945.286683] Call Trace:[ 945.286952] [ 945.287184] ? crypt_message+0x33f/0xad0 [cifs][ 945.287719] crypto_gcm_encrypt+0x36/0xe0[ 945.288152] crypt_message+0x54a/0xad0 [cifs][ 945.288724] smb3_init_transform_rq+0x277/0x300 [cifs][ 945.289300] smb_send_rqst+0xa3/0x160 [cifs][ 945.289944] cifs_call_async+0x178/0x340 [cifs][ 945.290514] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs][ 945.291177] smb2_async_writev+0x3e3/0x670 [cifs][ 945.291759] ? find_held_lock+0x32/0x90[ 945.292212] ? netfs_advance_write+0xf2/0x310[ 945.292723] netfs_advance_write+0xf2/0x310[ 945.293210] netfs_write_folio+0x346/0xcc0[ 945.293689] ? __pfx__raw_spin_unlock_irq+0x10/0x10[ 945.294250] netfs_writepages+0x117/0x460[ 945.294724] do_writepages+0xbe/0x170[ 945.295152] ? find_held_lock+0x32/0x90[ 945.295600] ? kvm_sched_clock_read+0x11/0x20[ 945.296103] __writeback_single_inode+0x56/0x4b0[ 945.296643] writeback_sb_inodes+0x229/0x550[ 945.297140] __writeback_inodes_wb+0x4c/0xe0[ 945.297642] wb_writeback+0x2f1/0x3f0[ 945.298069] wb_workfn+0x300/0x490[ 945.298472] process_one_work+0x1fe/0x590[ 945.298949] worker_thread+0x1ce/0x3c0[ 945.299397] ? __pfx_worker_thread+0x10/0x10[ 945.299900] kthr---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40053 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dlink: handle copy_thresh allocation failureThe driver did not handle failure of `netdev_alloc_skb_ip_align()`.If the allocation failed, dereferencing `skb->protocol` could lead toa NULL pointer dereference.This patch tries to allocate `skb`. If the allocation fails, it fallsback to the normal path.Tested-on: D-Link DGE-550T Rev-A3

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40055 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix double free in user_cluster_connect()user_cluster_disconnect() frees "conn->cc_private" which is "lc" but thenthe error handling frees "lc" a second time. Set "lc" to NULL on thispath to avoid a double free.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40058 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Disallow dirty tracking if incoherent page walkDirty page tracking relies on the IOMMU atomically updating the dirty bitin the paging-structure entry. For this operation to succeed, the paging-structure memory must be coherent between the IOMMU and the CPU. Inanother word, if the iommu page walk is incoherent, dirty page trackingdoesn't work.The Intel VT-d specification, Section 3.10 "Snoop Behavior" states:"Remapping hardware encountering the need to atomically update A/EA/D bits in a paging-structure entry that is not snooped will result in a non- recoverable fault."To prevent an IOMMU from being incorrectly configured for dirty pagetracking when it is operating in an incoherent mode, mark SSADS assupported only when both ecap_slads and ecap_smpwc are supported.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40059 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:coresight: Fix incorrect handling for return value of devm_kzallocThe return value of devm_kzalloc could be an null pointer,use "!desc.pdata" to fix incorrect handling return valueof devm_kzalloc.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40060 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:coresight: trbe: Return NULL pointer for allocation failuresWhen the TRBE driver fails to allocate a buffer, it currently returnsthe error code "-ENOMEM". However, the caller etm_setup_aux() onlychecks for a NULL pointer, so it misses the error. As a result, thedriver continues and eventually causes a kernel panic.Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() onallocation failures. This allows that the callers can properly handlethe failure.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40061 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix race in do_task() when drainingWhen do_task() exhausts its iteration budget (!ret), it sets the stateto TASK_STATE_IDLE to reschedule, without a secondary check on thecurrent task->state. This can overwrite the TASK_STATE_DRAINING stateset by a concurrent call to rxe_cleanup_task() or rxe_disable_task().While state changes are protected by a spinlock, both rxe_cleanup_task()and rxe_disable_task() release the lock while waiting for the task tofinish draining in the while(!is_done(task)) loop. The race occurs ifdo_task() hits its iteration limit and acquires the lock in this window.The cleanup logic may then proceed while the task incorrectlyreschedules itself, leading to a potential use-after-free.This bug was introduced during the migration from tasklets to workqueues,where the special handling for the draining case was lost.Fix this by restoring the original pre-migration behavior. If the state isTASK_STATE_DRAINING when iterations are exhausted, set cont to 1 toforce a new loop iteration. This allows the task to finish its work, sothat a subsequent iteration can reach the switch statement and correctlytransition the state to TASK_STATE_DRAINED, stopping the task as intended.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40062 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regsWhen the initialization of qm->debug.acc_diff_reg fails,the probe process does not exit. However, after qm->debug.qm_diff_regs isfreed, it is not set to NULL. This can lead to a double free when theremove process attempts to free it again. Therefore, qm->debug.qm_diff_regsshould be set to NULL after it is freed.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40064 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smc: Fix use-after-free in __pnet_find_base_ndev().syzbot reported use-after-free of net_device in __pnet_find_base_ndev(),which was called during connect(). [0]smc_pnet_find_ism_resource() fetches sk_dst_get(sk)->dev and passesdown to pnet_find_base_ndev(), where RTNL is held. Then, UAF happenedat __pnet_find_base_ndev() when the dev is first used.This means dev had already been freed before acquiring RTNL inpnet_find_base_ndev().While dev is going away, dst->dev could be swapped with blackhole_netdev,and the dev's refcnt by dst will be released.We must hold dev's refcnt before calling smc_pnet_find_ism_resource().Also, smc_pnet_find_roce_resource() has the same problem.Let's use __sk_dst_get() and dst_dev_rcu() in the two functions.[0]:BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline] smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline] smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154 smc_find_ism_device net/smc/af_smc.c:1030 [inline] smc_find_proposal_devices net/smc/af_smc.c:1115 [inline] __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545 smc_connect+0x877/0xd90 net/smc/af_smc.c:1715 __sys_connect_file net/socket.c:2086 [inline] __sys_connect+0x313/0x440 net/socket.c:2105 __do_sys_connect net/socket.c:2111 [inline] __se_sys_connect net/socket.c:2108 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2108 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/0x7fRIP: 0033:0x7f47cbf8eba9Code: 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 48RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000bRBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8 The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bacflags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as freedpage last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kvmalloc_node---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40070 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pps: fix warning in pps_register_cdev when register device failSimilar to previous commit 2a934fdb01db ("media: v4l2-dev: fix errorhandling in __video_register_device()"), the release hook should be setbefore device_register(). Otherwise, when device_register() return errorand put_device() try to callback the release function, the below warningmay happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567 Modules linked in: CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567 Call Trace: kobject_cleanup+0x136/0x410 lib/kobject.c:689 kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0xe9/0x130 lib/kobject.c:737 put_device+0x24/0x30 drivers/base/core.c:3797 pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402 pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108 pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57 tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432 tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563 tiocsetd drivers/tty/tty_io.c:2429 [inline] tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e Before commit c79a39dc8d06 ("pps: Fix a use-after-free"),pps_register_cdev() call device_create() to create pps->dev, which willinit dev->release to device_create_release(). Now the comment is outdated,just remove it.Thanks for the reminder from Calvin Owens, 'kfree_pps' should be removedin pps_register_source() to avoid a double free in the failure case.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40071 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don't block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when openinga DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().If basic mode is used it calls gsm_modem_upd_via_msc() and itcannot block the input queue by waiting the response to comeinto the same input queue.Instead allow sending Modem Status Command without waiting for remoteend to respond. Define a new function gsm_modem_send_initial_msc()for this purpose. As MSC is only valid for basic encoding, it doesnot do anything for advanced or when convergence layer type 2 is used.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40074 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: start using dst_dev_rcu()Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40075 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: use dst_dev_net_rcu()Replace three dst_dev() with a lockdep enabled helper.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40078 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Explicitly check accesses to bpf_sock_addrSyzkaller found a kernel warning on the following sock_addr program: 0: r0 = 0 1: r2 = *(u32 *)(r1 +60) 2: exitwhich triggers: verifier bug: error during ctx access conversion (0)This is happening because offset 60 in bpf_sock_addr corresponds to animplicit padding of 4 bytes, right after msg_src_ip4. Access to thispadding isn't rejected in sock_addr_is_valid_access and it thus laterfails to convert the access.This patch fixes it by explicitly checking the various fields ofbpf_sock_addr in sock_addr_is_valid_access.I checked the other ctx structures and is_valid_access functions anddidn't find any other similar cases. Other cases of (properly handled)padding are covered in new tests in a subsequent patch.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40080 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nbd: restrict sockets to TCP and UDPRecently, syzbot started to abuse NBD with all kinds of sockets.Commit cf1b2326b734 ("nbd: verify socket is supported during setup")made sure the socket supported a shutdown() method.Explicitely accept TCP and UNIX stream sockets.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40081 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf: arm_spe: Prevent overflow in PERF_IDX2OFF()Cast nr_pages to unsigned long to avoid overflow when handling largeAUX buffer sizes (>= 2 GiB).

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40083 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix null-deref in agg_dequeueTo prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the returnvalue before using it, similar to the existing approach in sch_hfsc.c.To avoid code duplication, the following changes are made:1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a staticinline function.2. Moved qdisc_peek_len from net/sched/sch_hfsc.c toinclude/net/pkt_sched.h so that sch_qfq can reuse it.3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40087 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Define a proc_layoutcommit for the FlexFiles layout typeAvoid a crash if a pNFS client should happen to send a LAYOUTCOMMIToperation on a FlexFiles layout.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40098 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state()Return value of a function acpi_evaluate_dsm() is dereferenced withoutchecking for NULL, but it is usually checked for this function.acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returnsacpi_status other than ACPI_SUCCESS, so add a check to prevent the crach.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40100 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not assert we found block group item when creating free space treeCurrently, when building a free space tree at populate_free_space_tree(),if we are not using the block group tree feature, we always expect to findblock group items (either extent items or a block group item with key typeBTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree withbtrfs_search_slot_for_read(), so we assert that we found an item. Howeverthis expectation is wrong since we can have a new block group created inthe current transaction which is still empty and for which we still havenot added the block group's item to the extent tree, in which case we donot have any items in the extent tree associated to the block group.The insertion of a new block group's block group item in the extent treehappens at btrfs_create_pending_block_groups() when it calls the helperinsert_block_group_item(). This typically is done when a transactionhandle is released, committed or when running delayed refs (either aspart of a transaction commit or when serving tickets for space reservationif we are low on free space).So remove the assertion at populate_free_space_tree() even when the blockgroup tree feature is not enabled and update the comment to mention thiscase.Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1115! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115 Code: ff ff e8 d3 (...) RSP: 0018:ffffc9000430f780 EFLAGS: 00010246 RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94 R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001 R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000 FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0 Call Trace: btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364 btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062 btrfs_remount_rw fs/btrfs/super.c:1334 [inline] btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559 reconfigure_super+0x227/0x890 fs/super.c:1076 do_remount fs/namespace.c:3279 [inline] path_mount+0xd1a/0xfe0 fs/namespace.c:4027 do_mount fs/namespace.c:4048 [inline] __do_sys_mount fs/namespace.c:4236 [inline] __se_sys_mount+0x313/0x410 fs/namespace.c:4213 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f424e39066a Code: d8 64 89 02 (...) RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 Modules linked in: ---[ end trace 0000000000000000 ]---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40107 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabledThis issue is similar to the vulnerability in the `mcp251x` driver,which was fixed in commit 03c427147b2d ("can: mcp251x: fix resume fromsleep before interface was brought up").In the `hi311x` driver, when the device resumes from sleep, the driverschedules `priv->restart_work`. However, if the network interface wasnot previously enabled, the `priv->wq` (workqueue) is not allocated andinitialized, leading to a null pointer dereference.To fix this, we move the allocation and initialization of the workqueuefrom the `hi3110_open` function to the `hi3110_can_probe` function.This ensures that the workqueue is properly initialized before it isused during device resume. And added logic to destroy the workqueuein the error handling paths of `hi3110_can_probe` and in the`hi3110_can_remove` function to prevent resource leaks.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40109 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: rng - Ensure set_ent is always presentEnsure that set_ent is always set since only drbg provides it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40115 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Fix crash in transport port remove by using ioc_info()During mpt3sas_transport_port_remove(), messages were logged withdev_printk() against &mpt3sas_port->port->dev. At this point the SAStransport device may already be partially unregistered or freed, leadingto a crash when accessing its struct device.Using ioc_info(), which logs via the PCI device (ioc->pdev->dev),guaranteed to remain valid until driver removal.[83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI[83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G OE 6.16.0-rc1+ #1 PREEMPT(voluntary)[83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE[83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024[83428.295799] RIP: 0010:__dev_printk+0x1f/0x70[83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff[83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206[83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32[83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845[83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8[83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000[83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30[83428.295833] FS: 00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000[83428.295837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0[83428.295844] PKRU: 55555554[83428.295846] Call Trace:[83428.295848] [83428.295850] _dev_printk+0x5c/0x80[83428.295857] ? srso_alias_return_thunk+0x5/0xfbef5[83428.295863] mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas][83428.295882] _scsih_remove_device+0x21b/0x280 [mpt3sas][83428.295894] ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas][83428.295906] ? srso_alias_return_thunk+0x5/0xfbef5[83428.295910] mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas][83428.295921] _scsih_expander_node_remove+0x129/0x140 [mpt3sas][83428.295933] _scsih_expander_node_remove+0x6a/0x140 [mpt3sas][83428.295944] scsih_remove+0x3f0/0x4a0 [mpt3sas][83428.295957] pci_device_remove+0x3b/0xb0[83428.295962] device_release_driver_internal+0x193/0x200[83428.295968] driver_detach+0x44/0x90[83428.295971] bus_remove_driver+0x69/0xf0[83428.295975] pci_unregister_driver+0x2a/0xb0[83428.295979] _mpt3sas_exit+0x1f/0x300 [mpt3sas][83428.295991] __do_sys_delete_module.constprop.0+0x174/0x310[83428.295997] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296000] ? __x64_sys_getdents64+0x9a/0x110[83428.296005] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296009] ? syscall_trace_enter+0xf6/0x1b0[83428.296014] do_syscall_64+0x7b/0x2c0[83428.296019] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296023] entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40116 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: host: max3421-hcd: Fix error pointer dereference in probe cleanupThe kthread_run() function returns error pointers so themax3421_hcd->spi_thread pointer can be either error pointers or NULL.Check for both before dereferencing it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40120 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlockPrevent USB runtime PM (autosuspend) for AX88772* in bind.usbnet enables runtime PM (autosuspend) by default, so disabling it viathe usb_driver flag is ineffective. On AX88772B, autosuspend shows nomeasurable power saving with current driver (no link partner, adminup/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib poweringthe PHY off on admin-down, not from USB autosuspend.The real hazard is that with runtime PM enabled, ndo_open() (under RTNL)may synchronously trigger autoresume (usb_autopm_get_interface()) intoasix_resume() while the USB PM lock is held. Resume paths then invokephylink/phylib and MDIO, which also expect RTNL, leading to possibledeadlocks or PM lock vs MDIO wake issues.To avoid this, keep the device runtime-PM active by taking a usagereference in ax88772_bind() and dropping it in unbind(). A non-zero PMusage count blocks runtime suspend regardless of userspace policy(.../power/control - pm_runtime_allow/forbid), making this approachrobust against sysfs overrides.Holding a runtime-PM usage ref does not affect system-wide suspend;system sleep/resume callbacks continue to run as before.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40123 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Enforce expected_attach_type for tailcall compatibilityYinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object.The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as theentry point for bpf_prog_test_run_xdp() and its expected_attach_type canneither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slotof a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAPto pass xdp_is_valid_access() validation. The program returns struct xdp_md'segress_ifindex, and the latter is only allowed to be accessed under mentionedexpected_attach_type. progB is then inserted into the tailcall which progAcalls.The underlying issue goes beyond XDP though. Another example are programsof type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as wellas sock_addr_func_proto() have different logic depending on the programs'expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAMEshould not be allowed doing a tailcall into a program which calls bpf_bind()out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.In short, specifying expected_attach_type allows to open up additionalfunctionality or restrictions beyond what the basic bpf_prog_type enables.The use of tailcalls must not violate these constraints. Fix it by enforcingexpected_attach_type in __bpf_prog_map_compatible().Note that we only enforce this for tailcall maps, but not for BPF devmaps orcpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() andcpu_map_bpf_prog_run*() which set up a new environment / context and thereforethese situations are not prone to this issue.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40124 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC IIIAnthony Yznaga tracked down that a BUG_ON in ext4 code with large foliosenabled resulted from copy_from_user() returning impossibly large valuesgreater than the size to be copied. This lead to __copy_from_iter()returning impossible values instead of the actual number of bytes it wasable to copy.The BUG_ON has been reported inhttps://lore.kernel.org/r/b14f55642207e63e907965e209f6323a0df6dcee.camel@physik.fu-berlin.deThe referenced commit introduced exception handlers on user-space memoryreferences in copy_from_user and copy_to_user. These handlers return fromthe respective function and calculate the remaining bytes left to copyusing the current register contents. The exception handlers expect that%o2 has already been masked during the bulk copy loop, but the masking wasperformed after that loop. This will fix the return value of copy_from_userand copy_to_user in the faulting case. The behaviour of memcpy staysunchanged.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40125 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: check kobject state_in_sysfs before deleting in blk_mq_unregister_hctxIn __blk_mq_update_nr_hw_queues() the return value ofblk_mq_sysfs_register_hctxs() is not checked. If sysfs creation for hctxfails, later changing the number of hw_queues or removing disk willtrigger the following warning: kernfs: can not remove 'nr_tags', no directory WARNING: CPU: 2 PID: 637 at fs/kernfs/dir.c:1707 kernfs_remove_by_name_ns+0x13f/0x160 Call Trace: remove_files.isra.1+0x38/0xb0 sysfs_remove_group+0x4d/0x100 sysfs_remove_groups+0x31/0x60 __kobject_del+0x23/0xf0 kobject_del+0x17/0x40 blk_mq_unregister_hctx+0x5d/0x80 blk_mq_sysfs_unregister_hctxs+0x94/0xd0 blk_mq_update_nr_hw_queues+0x124/0x760 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x92/0x120 [null_blk]kobjct_del() was called unconditionally even if sysfs creation failed.Fix it by checkig the kobject creation statusbefore deleting it.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40127 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwrng: ks-sa - fix division by zero in ks_sa_rng_initFix division by zero in ks_sa_rng_init caused by missing clockpointer initialization. The clk_get_rate() call is performed onan uninitialized clk pointer, resulting in division by zero whencalculating delay values.Add clock initialization code before using the clock. drivers/char/hw_random/ks-sa-rng.c | 7 +++++++ 1 file changed, 7 insertions(+)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40132 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: sof_sdw: Prevent jump to NULL add_sidecar callbackIn create_sdw_dailink() check that sof_end->codec_info->add_sidecaris not NULL before calling it.The original code assumed that if include_sidecar is true, the codecon that link has an add_sidecar callback. But there could be othercodecs on the same link that do not have an add_sidecar callback.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40147 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-throttle: fix access race during throttle policy activationOn repeated cold boots we occasionally hit a NULL pointer crash inblk_should_throtl() when throttling is consulted before the throttlepolicy is fully enabled for the queue. Checking only q->td != NULL isinsufficient during early initialization, so blkg_to_pd() for thethrottle policy can still return NULL and blkg_to_tg() becomes NULL,which later gets dereferenced. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000156 ... pc : submit_bio_noacct+0x14c/0x4c8 lr : submit_bio_noacct+0x48/0x4c8 sp : ffff800087f0b690 x29: ffff800087f0b690 x28: 0000000000005f90 x27: ffff00068af393c0 x26: 0000000000080000 x25: 000000000002fbc0 x24: ffff000684ddcc70 x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 x20: 0000000000080000 x19: ffff000684ddcd08 x18: ffffffffffffffff x17: 0000000000000000 x16: ffff80008132a550 x15: 0000ffff98020fff x14: 0000000000000000 x13: 1fffe000d11d7021 x12: ffff000688eb810c x11: ffff00077ec4bb80 x10: ffff000688dcb720 x9 : ffff80008068ef60 x8 : 00000a6fb8a86e85 x7 : 000000000000111e x6 : 0000000000000002 x5 : 0000000000000246 x4 : 0000000000015cff x3 : 0000000000394500 x2 : ffff000682e35e40 x1 : 0000000000364940 x0 : 000000000000001a Call trace: submit_bio_noacct+0x14c/0x4c8 verity_map+0x178/0x2c8 __map_bio+0x228/0x250 dm_submit_bio+0x1c4/0x678 __submit_bio+0x170/0x230 submit_bio_noacct_nocheck+0x16c/0x388 submit_bio_noacct+0x16c/0x4c8 submit_bio+0xb4/0x210 f2fs_submit_read_bio+0x4c/0xf0 f2fs_mpage_readpages+0x3b0/0x5f0 f2fs_readahead+0x90/0xe8Tighten blk_throtl_activated() to also require that the throttle policybit is set on the queue: return q->td != NULL && test_bit(blkcg_policy_throtl.plid, q->blkcg_pols);This prevents blk_should_throtl() from accessing throttle group stateuntil policy data has been attached to blkgs.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40155 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: debugfs: Fix legacy mode page table dump logicIn legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTRmaybe uninitialized or zero in that case and may cause oops like: Oops: general protection fault, probably for non-canonical address 0xf00087d3f000f000: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 RIP: 0010:pgtable_walk_level+0x98/0x150 RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206 RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000 RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000 R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98 FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: pgtable_walk_level+0x88/0x150 domain_translation_struct_show.isra.0+0x2d9/0x300 dev_domain_translation_struct_show+0x20/0x40 seq_read_iter+0x12d/0x490...Avoid walking the page table if TT is not 00b or 01b.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40156 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe()The drv->sram_reg pointer could be set to ERR_PTR(-EPROBE_DEFER) whichwould lead to a error pointer dereference. Use IS_ERR_OR_NULL() to checkthat the pointer is valid.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40162 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: amd/sdw_utils: avoid NULL deref when devm_kasprintf() failsdevm_kasprintf() may return NULL on memory allocation failure,but the debug message prints cpus->dai_name before checking it.Move the dev_dbg() call after the NULL check to prevent potentialNULL pointer dereference.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40166 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/guc: Check GuC running state before deregistering exec queueIn normal operation, a registered exec queue is disabled andderegistered through the GuC, and freed only after the GuC confirmscompletion. However, if the driver is forced to unbind while the execqueue is still running, the user may call exec_destroy() after the GuChas already been stopped and CT communication disabled.In this case, the driver cannot receive a response from the GuC,preventing proper cleanup of exec queue resources. Fix this by directlyreleasing the resources when GuC is not running.Here is the failure dmesg log:"[ 468.089581] ---[ end trace 0000000000000000 ]---[ 468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535)[ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535[ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1[ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1)[ 468.092716] ------------[ cut here ]------------[ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe]"v2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled(). As CT may go down and come back during VF migration.(cherry picked from commit 9b42321a02c50a12b2beb6ae9469606257fbecea)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40167 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: detect invalid INLINE_DATA + EXTENTS flag combinationsyzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verityfile on a corrupted ext4 filesystem mounted without a journal.The issue is that the filesystem has an inode with both the INLINE_DATAand EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1This is an invalid combination since an inode should have either:- INLINE_DATA: data stored directly in the inode- EXTENTS: data stored in extent-mapped blocksHaving both flags causes ext4_has_inline_data() to return true, skippingextent tree validation in __ext4_iget(). The unvalidated out-of-orderextents then trigger a BUG_ON in ext4_es_cache_extent() due to integerunderflow when calculating hole sizes.Fix this by detecting this invalid flag combination early in ext4_iget()and rejecting the corrupted inode.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40172 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages()Currently, if find_and_map_user_pages() takes a DMA xfer request from theuser with a length field set to 0, or in a rare case, the host receivesQAIC_TRANS_DMA_XFER_CONT from the device where resources->xferred_dma_sizeis equal to the requested transaction size, the function will return 0before allocating an sgt or setting the fields of the dma_xfer struct.In that case, encode_addr_size_pairs() will try to access the sgt whichwill lead to a general protection fault.Return an EINVAL in case the user provides a zero-sized ALP, or the devicerequests continuation after all of the bytes have been transferred.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40181 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNPWhen running as an SNP or TDX guest under KVM, force the legacy PCI hole,i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UCvia a forced variable MTRR range.In most KVM-based setups, legacy devices such as the HPET and TPM areenumerated via ACPI. ACPI enumeration includes a Memory32Fixed entry, andoptionally a SystemMemory descriptor for an OperationRegion, e.g. if thedevice needs to be accessed via a Control Method.If a SystemMemory entry is present, then the kernel's ACPI driver willauto-ioremap the region so that it can be accessed at will. However, theACPI spec doesn't provide a way to enumerate the memory type ofSystemMemory regions, i.e. there's no way to tell software that a regionmust be mapped as UC vs. WB, etc. As a result, Linux's ACPI driver alwaysmaps SystemMemory regions using ioremap_cache(), i.e. as WB on x86.The dedicated device drivers however, e.g. the HPET driver and TPM driver,want to map their associated memory as UC or WC, as accessing PCI devicesusing WB is unsupported.On bare metal and non-CoCO, the conflicting requirements "work" as firmwareconfigures the PCI hole (and other device memory) to be UC in the MTRRs.So even though the ACPI mappings request WB, they are forced to UC- in thekernel's tracking due to the kernel properly handling the MTRR overrides,and thus are compatible with the drivers' requested WC/UC-.With force WB MTRRs on SNP and TDX guests, the ACPI mappings get theirrequested WB if the ACPI mappings are established before the dedicateddriver code attempts to initialize the device. E.g. if acpi_init()runs before the corresponding device driver is probed, ACPI's WB mappingwill "win", and result in the driver's ioremap() failing because theexisting WB mapping isn't compatible with the requested WC/UC-.E.g. when a TPM is emulated by the hypervisor (ignoring the securityimplications of relying on what is allegedly an untrusted entity to storemeasurements), the TPM driver will request UC and fail: [ 1.730459] ioremap error for 0xfed40000-0xfed45000, requested 0x2, got 0x0 [ 1.732780] tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -12Note, the '0x2' and '0x0' values refer to "enum page_cache_mode", not x86'smemtypes (which frustratingly are an almost pure inversion; 2 == WB, 0 == UC).E.g. tracing mapping requests for TPM TIS yields: Mapping TPM TIS with req_type = 0 WARNING: CPU: 22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460 Modules linked in: CPU: 22 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.16.0-rc7+ #2 VOLUNTARY Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025 RIP: 0010:memtype_reserve+0x2ab/0x460 __ioremap_caller+0x16d/0x3d0 ioremap_cache+0x17/0x30 x86_acpi_os_ioremap+0xe/0x20 acpi_os_map_iomem+0x1f3/0x240 acpi_os_map_memory+0xe/0x20 acpi_ex_system_memory_space_handler+0x273/0x440 acpi_ev_address_space_dispatch+0x176/0x4c0 acpi_ex_access_region+0x2ad/0x530 acpi_ex_field_datum_io+0xa2/0x4f0 acpi_ex_extract_from_field+0x296/0x3e0 acpi_ex_read_data_from_field+0xd1/0x460 acpi_ex_resolve_node_to_value+0x2ee/0x530 acpi_ex_resolve_to_value+0x1f2/0x540 acpi_ds_evaluate_name_path+0x11b/0x190 acpi_ds_exec_end_op+0x456/0x960 acpi_ps_parse_loop+0x27a/0xa50 acpi_ps_parse_aml+0x226/0x600 acpi_ps_execute_method+0x172/0x3e0 acpi_ns_evaluate+0x175/0x5f0 acpi_evaluate_object+0x213/0x490 acpi_evaluate_integer+0x6d/0x140 acpi_bus_get_status+0x93/0x150 acpi_add_single_object+0x43a/0x7c0 acpi_bus_check_add+0x149/0x3a0 acpi_bus_check_add_1+0x16/0x30 acpi_ns_walk_namespace+0x22c/0x360 acpi_walk_namespace+0x15c/0x170 acpi_bus_scan+0x1dd/0x200 acpi_scan_init+0xe5/0x2b0 acpi_init+0x264/0x5b0 do_one_i---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40185 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: ice_adapter: release xa entry on adapter allocation failureWhen ice_adapter_new() fails, the reserved XArray entry created byxa_insert() is not released. This causes subsequent insertions atthe same index to return -EBUSY, potentially leading toNULL pointer dereferences.Reorder the operations as suggested by Przemek Kitszel:1. Check if adapter already exists (xa_load)2. Reserve the XArray slot (xa_reserve)3. Allocate the adapter (ice_adapter_new)4. Store the adapter (xa_store)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40188 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pwm: berlin: Fix wrong register in suspend/resumeThe 'enable' register should be BERLIN_PWM_EN rather thanBERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, therewill be cpu exception then kernel panic during suspend/resume.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40192 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Revert "ipmi: fix msg stack when IPMI is disconnected"This reverts commit c608966f3f9c2dca596967501d00753282b395fc.This patch has a subtle bug that can cause the IPMI driver to go into aninfinite loop if the BMC misbehaves in a certain way. Apparentlycertain BMCs do misbehave this way because several reports have come inrecently about this.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40197 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: mc: Clear minor number before put deviceThe device minor should not be cleared after the device is released.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40198 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()Unlike other strings in the ext4 superblock, we rely on tune2fs tomake sure s_mount_opts is NUL terminated. Hardenparse_apply_sb_mount_options() by treating s_mount_opts as a potential__nonstring.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40200 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: reject negative file sizes in squashfs_read_inode()Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs.This warning is ultimately caused because the underlying Squashfs filesystem returns a file with a negative file size.This commit checks for a negative file size and returns EINVAL.[phillip@squashfs.org.uk: only need to check 64 bit quantity]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40201 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() pathsThe usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit()path is very broken.sys_prlimit64() does get_task_struct(tsk) but this only protects task_structitself. If tsk != current and tsk is not a leader, this process can exit/execand task_lock(tsk->group_leader) may use the already freed task_struct.Another problem is that sys_prlimit64() can race with mt-exec which changes->group_leader. In this case do_prlimit() may take the wrong lock, or (worse)->group_leader may change between task_lock() and task_unlock().Change sys_prlimit64() to take tasklist_lock when necessary. This is notnice, but I don't see a better fix for -stable.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40202 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipmi: Rework user message limit handlingThe limit on the number of user messages had a number of issues,improper counting in some cases and a use after free.Restructure how this is all done to handle more in the receive messageallocation routine, so all refcouting and user message limit countsare done in that routine. It's a lot cleaner and safer.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40203 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:listmount: don't call path_put() under namespace semaphoreMassage listmount() and make sure we don't call path_put() under thenamespace semaphore. If we put the last reference we're fscked.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40205 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: avoid potential out-of-bounds in btrfs_encode_fh()The function btrfs_encode_fh() does not properly account for the threecases it handles.Before writing to the file handle (fh), the function only returns to theuser BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) orBTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).However, when a parent exists and the root ID of the parent and theinode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT(10 dwords, 40 bytes).If *max_len is not large enough, this write goes out of bounds becauseBTRFS_FID_SIZE_CONNECTABLE_ROOT is greater thanBTRFS_FID_SIZE_CONNECTABLE originally returned.This results in an 8-byte out-of-bounds write atfid->parent_root_objectid = parent_root_id.A previous attempt to fix this issue was made but was lost.https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/Although this issue does not seem to be easily triggerable, it is apotential memory corruption bug that should be fixed. This patchresolves the issue by ensuring the function returns the appropriate sizefor all three cases and validates that *max_len is large enough beforewriting any data.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40207 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try()v4l2_subdev_call_state_try() macro allocates a subdev state with__v4l2_subdev_state_alloc(), but does not check the returned value. If__v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that wouldcause v4l2_subdev_call_state_try() to crash.Add proper error handling to v4l2_subdev_call_state_try().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40217 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pidfs: validate extensible ioctlsValidate extensible ioctls stricter than we do now.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40218 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/vaddr: do not repeat pte_offset_map_lock() until successDAMON's virtual address space operation set implementation (vaddr) callspte_offset_map_lock() inside the page table walk callback function. Thisis for reading and writing page table accessed bits. Ifpte_offset_map_lock() fails, it retries by returning the page table walkcallback function with ACTION_AGAIN.pte_offset_map_lock() can continuously fail if the target is a pmdmigration entry, though. Hence it could cause an infinite page table walkif the migration cannot be done until the page table walk is finished. This indeed caused a soft lockup when CPU hotplugging and DAMON wererunning in parallel.Avoid the infinite loop by simply not retrying the page table walk. DAMONis promising only a best-effort accuracy, so missing access to such pagesis no problem.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40223 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: Fix use-after-free in hdm_disconnecthdm_disconnect() calls most_deregister_interface(), which eventuallyunregisters the MOST interface device with device_unregister(iface->dev).If that drops the last reference, the device core may call release_mdev()immediately while hdm_disconnect() is still executing.The old code also freed several mdev-owned allocations inhdm_disconnect() and then performed additional put_device() calls.Depending on refcount order, this could lead to use-after-free ordouble-free when release_mdev() ran (or when unregister paths alsoperformed puts).Fix by moving the frees of mdev-owned allocations into release_mdev(),so they happen exactly once when the device is truly released, and bydropping the extra put_device() calls in hdm_disconnect() that areredundant after device_unregister() and most_deregister_interface().This addresses the KASAN slab-use-after-free reported by syzbot inhdm_disconnect(). See report and stack traces in the bug link below.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40225 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Fix kernel panic on partial unmap of a GPU VA regionThis commit address a kernel panic issue that can happen if Userspacetries to partially unmap a GPU virtual region (aka drm_gpuva).The VM_BIND interface allows partial unmapping of a BO.Panthor driver pre-allocates memory for the new drm_gpuva structuresthat would be needed for the map/unmap operation, done using drm_gpuvmlayer. It expected that only one new drm_gpuva would be needed on umapbut a partial unmap can require 2 new drm_gpuva and that's why itended up doing a NULL pointer dereference causing a kernel panic.Following dump was seen when partial unmap was exercised. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000078 Mem abort info: ESR = 0x0000000096000046 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000088a863000 [000000000000078] pgd=080000088a842003, p4d=080000088a842003, pud=0800000884bf5003, pmd=0000000000000000 Internal error: Oops: 0000000096000046 [#1] PREEMPT SMP pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor] lr : panthor_gpuva_sm_step_remap+0x6c/0x330 [panthor] sp : ffff800085d43970 x29: ffff800085d43970 x28: ffff00080363e440 x27: ffff0008090c6000 x26: 0000000000000030 x25: ffff800085d439f8 x24: ffff00080d402000 x23: ffff800085d43b60 x22: ffff800085d439e0 x21: ffff00080abdb180 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000010 x17: 6e656c202c303030 x16: 3666666666646466 x15: 393d61766f69202c x14: 312d3d7361203a70 x13: 303030323d6e656c x12: ffff80008324bf58 x11: 0000000000000003 x10: 0000000000000002 x9 : ffff8000801a6a9c x8 : ffff00080360b300 x7 : 0000000000000000 x6 : 000000088aa35fc7 x5 : fff1000080000000 x4 : ffff8000842ddd30 x3 : 0000000000000001 x2 : 0000000100000000 x1 : 0000000000000001 x0 : 0000000000000078 Call trace: panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor] op_remap_cb.isra.22+0x50/0x80 __drm_gpuvm_sm_unmap+0x10c/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xb4/0x3d0 [panthor] panthor_vm_bind_exec_sync_op+0x154/0x278 [panthor] panthor_ioctl_vm_bind+0x160/0x4a0 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x240/0x500 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40226 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scmi: Account for failed debug initializationWhen the SCMI debug subsystem fails to initialize, the related debug rootwill be missing, and the underlying descriptor will be NULL.Handle this fault condition in the SCMI debug helpers that maintainmetrics counters.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40230 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: prevent poison consumption when splitting THPWhen performing memory error injection on a THP (Transparent Huge Page)mapped to userspace on an x86 server, the kernel panics with the followingtrace. The expected behavior is to terminate the affected process insteadof panicking the kernel, as the x86 Machine Check code can recover from anin-userspace #MC. mce: [Hardware Error]: CPU 0: Machine Check Exception: f Bank 3: bd80000000070134 mce: [Hardware Error]: RIP 10: {memchr_inv+0x4c/0xf0} mce: [Hardware Error]: TSC afff7bbff88a ADDR 1d301b000 MISC 80 PPIN 1e741e77539027db mce: [Hardware Error]: PROCESSOR 0:d06d0 TIME 1758093249 SOCKET 0 APIC 0 microcode 80000320 mce: [Hardware Error]: Run the above through 'mcelog --ascii' mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel Kernel panic - not syncing: Fatal local machine checkThe root cause of this panic is that handling a memory failure triggeredby an in-userspace #MC necessitates splitting the THP. The splittingprocess employs a mechanism, implemented intry_to_map_unused_to_zeropage(), which reads the pages in the THP toidentify zero-filled pages. However, reading the pages in the THP resultsin a second in-kernel #MC, occurring before the initial memory_failure()completes, ultimately leading to a kernel panic. See the kernel paniccall trace on the two #MCs. First Machine Check occurs // [1] memory_failure() // [2] try_to_split_thp_page() split_huge_page() split_huge_page_to_list_to_order() __folio_split() // [3] remap_page() remove_migration_ptes() remove_migration_pte() try_to_map_unused_to_zeropage() // [4] memchr_inv() // [5] Second Machine Check occurs // [6] Kernel panic[1] Triggered by accessing a hardware-poisoned THP in userspace, which is typically recoverable by terminating the affected process.[2] Call folio_set_has_hwpoisoned() before try_to_split_thp_page().[3] Pass the RMP_USE_SHARED_ZEROPAGE remap flag to remap_page().[4] Try to map the unused THP to zeropage.[5] Re-access pages in the hw-poisoned THP in the kernel.[6] Triggered in-kernel, leading to a panic kernel.In Step[2], memory_failure() sets the poisoned flag on the page in the THPby TestSetPageHWPoison() before calling try_to_split_thp_page().As suggested by David Hildenbrand, fix this panic by not accessing to thepoisoned page in the THP during zeropage identification, while continuingto scan unaffected pages in the THP for possible zeropage mapping. Thisprevents a second in-kernel #MC that would cause kernel panic in Step[4].Thanks to Andrew Zaborowski for his initial work on fixing this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40231 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: fix lock inversion in vsock_assign_transport()Syzbot reported a potential lock inversion deadlock betweenvsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.The issue was introduced by commit 687aa0c5581b ("vsock: Fixtransport_* TOCTOU") which added vsock_register_mutex locking invsock_assign_transport() around the transport->release() call, that cancall vsock_linger(). vsock_assign_transport() can be called with sk_lockheld. vsock_linger() calls sk_wait_event() that temporarily releases andre-acquires sk_lock. During this window, if another thread holdvsock_register_mutex while trying to acquire sk_lock, a circulardependency is created.Fix this by releasing vsock_register_mutex before callingtransport->release() and vsock_deassign_transport(). This is safebecause we don't need to hold vsock_register_mutex while releasing theold transport, and we ensure the new transport won't disappear byobtaining a module reference first via try_module_get().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40233 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: clear extent cache after moving/defragmenting extentsThe extent map cache can become stale when extents are moved ordefragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().The problem occurs when:1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED2. ioctl(FITRIM) triggers ocfs2_move_extents()3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)5. The extent map cache is not invalidated after the move6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggersFix by clearing the extent map cache after each extent move/defragoperation in __ocfs2_move_extents_range(). This ensures subsequentoperations read fresh extent data from disk.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40235 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: directly free partially initialized fs_info in btrfs_check_leaked_roots()If fs_info->super_copy or fs_info->super_for_commit allocated failed inbtrfs_get_tree_subvol(), then no need to call btrfs_free_fs_info().Otherwise btrfs_check_leaked_roots() would access NULL pointer becausefs_info->allocated_roots had not been initialised.syzkaller reported the following information: ------------[ cut here ]------------ BUG: unable to handle page fault for address: fffffffffffffbb0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 64c9067 P4D 64c9067 PUD 64cb067 PMD 0 Oops: Oops: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 1402 Comm: syz.1.35 Not tainted 6.15.8 #4 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), (...) RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:23 [inline] RIP: 0010:raw_atomic_read include/linux/atomic/atomic-arch-fallback.h:457 [inline] RIP: 0010:atomic_read include/linux/atomic/atomic-instrumented.h:33 [inline] RIP: 0010:refcount_read include/linux/refcount.h:170 [inline] RIP: 0010:btrfs_check_leaked_roots+0x18f/0x2c0 fs/btrfs/disk-io.c:1230 [...] Call Trace: btrfs_free_fs_info+0x310/0x410 fs/btrfs/disk-io.c:1280 btrfs_get_tree_subvol+0x592/0x6b0 fs/btrfs/super.c:2029 btrfs_get_tree+0x63/0x80 fs/btrfs/super.c:2097 vfs_get_tree+0x98/0x320 fs/super.c:1759 do_new_mount+0x357/0x660 fs/namespace.c:3899 path_mount+0x716/0x19c0 fs/namespace.c:4226 do_mount fs/namespace.c:4239 [inline] __do_sys_mount fs/namespace.c:4450 [inline] __se_sys_mount fs/namespace.c:4427 [inline] __x64_sys_mount+0x28c/0x310 fs/namespace.c:4427 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x92/0x180 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f032eaffa8d [...]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs/notify: call exportfs_encode_fid with s_umountCalling intotify_show_fdinfo() on fd watching an overlayfs inode, whilethe overlayfs is being unmounted, can lead to dereferencing NULL ptr.This issue was found by syzkaller.Race Condition Diagram:Thread 1 Thread 2-------- --------generic_shutdown_super() shrink_dcache_for_umount sb->s_root = NULL | | vfs_read() | inotify_fdinfo() | * inode get from mark * | show_mark_fhandle(m, inode) | exportfs_encode_fid(inode, ..) | ovl_encode_fh(inode, ..) | ovl_check_encode_origin(inode) | * deref i_sb->s_root * | | v fsnotify_sb_delete(sb)Which then leads to:[ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI[ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037][ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)[ 32.143353] Call Trace:[ 32.143732] ovl_encode_fh+0xd5/0x170[ 32.144031] exportfs_encode_inode_fh+0x12f/0x300[ 32.144425] show_mark_fhandle+0xbe/0x1f0[ 32.145805] inotify_fdinfo+0x226/0x2d0[ 32.146442] inotify_show_fdinfo+0x1c5/0x350[ 32.147168] seq_show+0x530/0x6f0[ 32.147449] seq_read_iter+0x503/0x12a0[ 32.148419] seq_read+0x31f/0x410[ 32.150714] vfs_read+0x1f0/0x9e0[ 32.152297] ksys_read+0x125/0x240IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was setto NULL in the unmount path.Fix it by protecting calling exportfs_encode_fid() fromshow_mark_fhandle() with s_umount lock.This form of fix was suggested by Amir in [1].[1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40238 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix IPsec cleanup over MPV deviceWhen we do mlx5e_detach_netdev() we eventually disable blocking eventsnotifier, among those events are IPsec MPV events from IB to core.So before disabling those blocking events, make sure to also unregisterthe devcom device and mark all this device operations as complete,in order to prevent the other device from using invalid netdevduring future devcom events which could cause the trace below.BUG: kernel NULL pointer dereference, address: 0000000000000010PGD 146427067 P4D 146427067 PUD 146488067 PMD 0Oops: Oops: 0000 [#1] SMPCPU: 1 UID: 0 PID: 7735 Comm: devlink Tainted: GW 6.12.0-rc6_for_upstream_min_debug_2024_11_08_00_46 #1Tainted: [W]=WARNHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core]Code: 00 01 48 83 05 23 32 1e 00 01 41 b8 ed ff ff ff e9 60 ff ff ff 48 83 05 00 32 1e 00 01 eb e3 66 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 47 10 48 83 05 5f 32 1e 00 01 48 8b 50 40 48 85 d2 74 05 40RSP: 0018:ffff88811a5c35f8 EFLAGS: 00010206RAX: ffff888106e8ab80 RBX: ffff888107d7e200 RCX: ffff88810d6f0a00RDX: ffff88810d6f0a00 RSI: 0000000000000001 RDI: 0000000000000000RBP: ffff88811a17e620 R08: 0000000000000040 R09: 0000000000000000R10: ffff88811a5c3618 R11: 0000000de85d51bd R12: ffff88811a17e600R13: ffff88810d6f0a00 R14: 0000000000000000 R15: ffff8881034bda80FS: 00007f27bdf89180(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000010 CR3: 000000010f159005 CR4: 0000000000372eb0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] mlx5e_devcom_event_mpv+0x42/0x60 [mlx5_core] mlx5_devcom_send_event+0x8c/0x170 [mlx5_core] blocking_event+0x17b/0x230 [mlx5_core] notifier_call_chain+0x35/0xa0 blocking_notifier_call_chain+0x3d/0x60 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core] mlx5_core_mp_event_replay+0x12/0x20 [mlx5_core] mlx5_ib_bind_slave_port+0x228/0x2c0 [mlx5_ib] mlx5_ib_stage_init_init+0x664/0x9d0 [mlx5_ib] ? idr_alloc_cyclic+0x50/0xb0 ? __kmalloc_cache_noprof+0x167/0x340 ? __kmalloc_noprof+0x1a7/0x430 __mlx5_ib_add+0x34/0xd0 [mlx5_ib] mlx5r_probe+0xe9/0x310 [mlx5_ib] ? kernfs_add_one+0x107/0x150 ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] auxiliary_bus_probe+0x3e/0x90 really_probe+0xc5/0x3a0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x86/0xa0 device_add+0x62d/0x830 __auxiliary_device_add+0x3b/0xa0 ? auxiliary_device_init+0x41/0x90 add_adev+0xd1/0x150 [mlx5_core] mlx5_rescan_drivers_locked+0x21c/0x300 [mlx5_core] esw_mode_change+0x6c/0xc0 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x21e/0x640 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xe0 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x180/0x2b0 ? devlink_get_from_attrs_lock+0x170/0x170 ? devlink_nl_eswitch_get_doit+0x290/0x290 ? devlink_nl_pre_doit_port_optional+0x50/0x50 ? genl_family_rcv_msg_dumpit+0xf0/0xf0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1fc/0x2d0 netlink_sendmsg+0x1e4/0x410 __sock_sendmsg+0x38/0x60 ? sockfd_lookup_light+0x12/0x60 __sys_sendto+0x105/0x160 ? __sys_recvmsg+0x4e/0x90 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7f27bc91b13aCode: bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 8b 05 fa 96 2c 00 45 89 c9 4c 63 d1 48 63 ff 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff ---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40239 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: micrel: always set shared->phydev for LAN8814Currently, during the LAN8814 PTP probe shared->phydev is only set if PTPclock gets actually set, otherwise the function will return before settingit.This is an issue as shared->phydev is unconditionally being used when IRQis being handled, especially in lan8814_gpio_process_cap and since it wasnot set it will cause a NULL pointer exception and crash the kernel.So, simply always set shared->phydev to avoid the NULL pointer exception.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40240 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: avoid NULL dereference when chunk data buffer is missingchunk->skb pointer is dereferenced in the if-block where it's supposedto be NULL only.chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_listinstead and do it just before replacing chunk->skb. We're sure thatotherwise chunk->skb is non-NULL because of outer if() condition.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40246 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: fix out of bounds memory read error in symlink repairxfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ==================================================================On further analysis, I realized that the second parameter to min() isnot correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_databuffer. if_bytes can be smaller than the data fork size because:(a) the forkoff code tries to keep the data area as large as possible(b) for symbolic links, if_bytes is the ondisk file size + 1(c) forkoff is always a multiple of 8.Case in point: for a single-byte symlink target, forkoff will be8 but the buffer will only be 2 bytes long.In other words, the logic here is wrong and we walk off the end of theincore buffer. Fix that.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40248 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Ignore signal/timeout on connect() if already establishedDuring connect(), acting on a signal/timeout by disconnecting an alreadyestablished socket leads to several issues:1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs.3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref.Do not disconnect socket on signal/timeout. Keep the logic for unconnectedsockets: they don't linger, can't be placed in a sockmap, are rejected bysendmsg().[1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/[2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/[3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40250 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Clean up only new IRQ glue on request_irq() failureThe mlx5_irq_alloc() function can inadvertently free the entire rmapand end up in a crash[1] when the other threads tries to access this,when request_irq() fails due to exhausted IRQ vectors. This commitmodifies the cleanup to remove only the specific IRQ mapping that wasjust added.This prevents removal of other valid mappings and ensures precisecleanup of the failed IRQ allocation's associated glue object.Note: This error is observed when both fwctl and rds configs are enabled.[1]mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed torequest irq. err = -28infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 whiletrying to test write-combining supportmlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed torequest irq. err = -28infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 whiletrying to test write-combining supportmlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed torequest irq. err = -28mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed torequest irq. err = -28general protection fault, probably for non-canonical address0xe277a58fde16f291: 0000 [#1] SMP NOPTIRIP: 0010:free_irq_cpu_rmap+0x23/0x7dCall Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0RIP: 0033:0x7fc328603727Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b edff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000dRBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000R13: 00000000000---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40251 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:devlink: rate: Unset parent pointer in devl_rate_nodes_destroyThe function devl_rate_nodes_destroy is documented to "Unset parent forall rate objects". However, it was only calling the driver-specific`rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementingthe parent's refcount, without actually setting the`devlink_rate->parent` pointer to NULL.This leaves a dangling pointer in the `devlink_rate` struct, which causerefcount error in netdevsim[1] and mlx5[2]. In addition, this isinconsistent with the behavior of `devlink_nl_rate_parent_node_set`,where the parent pointer is correctly cleared.This patch fixes the issue by explicitly setting `devlink_rate->parent`to NULL after notifying the driver, thus fulfilling the function'sdocumented behavior for all rate objects.[1]repro steps:echo 1 > /sys/bus/netdevsim/new_devicedevlink dev eswitch set netdevsim/netdevsim1 mode switchdevecho 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfsdevlink port function rate add netdevsim/netdevsim1/test_nodedevlink port function rate set netdevsim/netdevsim1/128 parent test_nodeecho 1 > /sys/bus/netdevsim/del_devicedmesg:refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:refcount_warn_saturate+0x42/0xe0Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2]devlink dev eswitch set pci/0000:08:00.0 mode switchdevdevlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000devlink port function rate add pci/0000:08:00.0/group1devlink port function rate set pci/0000:08:00.0/32768 parent group1modprobe -r mlx5_ib mlx5_fwctl mlx5_coredmesg:refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:refcount_warn_saturate+0x42/0xe0Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40252 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterateover 'cqe->len_list[]' using only a zero-length terminator asthe stopping condition. If the terminator was missing ormalformed, the loop could run past the end of the fixed-size array.Add an explicit bound check using ARRAY_SIZE() in both loops to preventa potential out-of-bounds access.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40253 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/ctcm: Fix double-kfreeThe function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionallyfrom function 'ctcmpc_unpack_skb'. It frees passed mpcginfo.After that a call to function 'kfree' in function 'ctcmpc_unpack_skb'frees it again.Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.Bug detected by the clang static analyzer.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40254 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: remove never-working support for setting nsh fieldsThe validation of the set(nsh(...)) action is completely wrong.It runs through the nsh_key_put_from_nlattr() function that is thesame function that validates NSH keys for the flow match and thepush_nsh() action. However, the set(nsh(...)) has a very differentmemory layout. Nested attributes in there are doubled in size incase of the masked set(). That makes proper validation impossible.There is also confusion in the code between the 'masked' flag, thatsays that the nested attributes are doubled in size containing boththe value and the mask, and the 'is_mask' that says that the valuewe're parsing is the mask. This is causing kernel crash on trying towrite into mask part of the match with SW_FLOW_KEY_PUT() duringvalidation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe third issue with this process is that while trying to convertthe non-masked set into masked one, validate_set() copies and doublesthe size of the OVS_KEY_ATTR_NSH as if it didn't have any nestedattributes. It should be copying each nested attribute and doublingthem in size independently. And the process must be properly reversedduring the conversion back from masked to a non-masked variant duringthe flow dump.In the end, the only two outcomes of trying to use this action areeither validation failure or a kernel crash. And if somehow someonemanages to install a flow with such an action, it will most definitelynot do what it is supposed to, since all the keys and the masks aremixed up.Fixing all the issues is a complex task as it requires re-writingmost of the validation code.Given that and the fact that this functionality never worked sinceintroduction, let's just remove it altogether. It's better tore-introduce it later with a proper implementation instead of tryingto fix it in stable releases.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40256 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: also call xfrm_state_delete_tunnel at destroy time for states that were never addedIn commit b441cf3f8c4b ("xfrm: delete x->tunnel as we delete x"), Imissed the case where state creation fails between fullinitialization (->init_state has been called) and being inserted onthe lists.In this situation, ->init_state has been called, so for IPcomptunnels, the fallback tunnel has been created and added onto thelists, but the user state never gets added, because we fail beforethat. The user state doesn't go through __xfrm_state_delete, so wedon't call xfrm_state_delete_tunnel for those states, and we end upleaking the FB tunnel.There are several codepaths affected by this: the add/update paths, inboth net/key and xfrm, and the migrate code (xfrm_migrate,xfrm_state_migrate). A "proper" rollback of the init_state work wouldprobably be doable in the add/update code, but for migrate it getsmore complicated as multiple states may be involved.At some point, the new (not-inserted) state will be destroyed, so callxfrm_state_delete_tunnel during xfrm_state_gc_destroy. Most stateswill have their fallback tunnel cleaned up during __xfrm_state_delete,which solves the issue that b441cf3f8c4b (and other patches before it)aimed at. All states (including FB tunnels) will be removed from thelists once xfrm_state_fini has called flush_work(&xfrm_state_gc_work).

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40259 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: sg: Do not sleep in atomic contextsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function maysleep. Hence, call sg_finish_rem_req() with interrupts enabled insteadof disabled.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40261 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()nvme_fc_delete_assocation() waits for pending I/O to complete beforereturning, and an error can cause ->ioerr_work to be queued aftercancel_work_sync() had been called. Move the call to cancel_work_sync() tobe after nvme_fc_delete_association() to ensure ->ioerr_work is not runningwhen the nvme_fc_ctrl object is freed. Otherwise the following can occur:[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL[ 1135.917705] ------------[ cut here ]------------[ 1135.922336] kernel BUG at lib/list_debug.c:52![ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary)[ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025[ 1135.950969] Workqueue: 0x0 (nvme-wq)[ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f[ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b[ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046[ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000[ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0[ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08[ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100[ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0[ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000[ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0[ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[ 1136.055910] PKRU: 55555554[ 1136.058623] Call Trace:[ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0[ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0[ 1136.071898] ? move_linked_works+0x4a/0xa0[ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.081744] ? __die_body.cold+0x8/0x12[ 1136.085584] ? die+0x2e/0x50[ 1136.088469] ? do_trap+0xca/0x110[ 1136.091789] ? do_error_trap+0x65/0x80[ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.101289] ? exc_invalid_op+0x50/0x70[ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20[ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.120806] move_linked_works+0x4a/0xa0[ 1136.124733] worker_thread+0x216/0x3a0[ 1136.128485] ? __pfx_worker_thread+0x10/0x10[ 1136.132758] kthread+0xfa/0x240[ 1136.135904] ? __pfx_kthread+0x10/0x10[ 1136.139657] ret_from_fork+0x31/0x50[ 1136.143236] ? __pfx_kthread+0x10/0x10[ 1136.146988] ret_from_fork_asm+0x1a/0x30[ 1136.150915]

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40262 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: imx_sc_key - fix memory corruption on unloadThis is supposed to be "priv" but we accidentally pass "&priv" which isan address in the stack and so it will lead to memory corruption whenthe imx_sc_key_action() function is called. Remove the &.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40263 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: cros_ec_keyb - fix an invalid memory accessIf cros_ec_keyb_register_matrix() isn't called (due to`buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remainsNULL. An invalid memory access is observed in cros_ec_keyb_process()when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work()in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_threadIt's still unknown about why the kernel receives such malformed event,in any cases, the kernel shouldn't access `ckdev->idev` and friends ifthe driver doesn't intend to initialize them.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40264 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:be2net: pass wrb_params in case of OS2BMCbe_insert_vlan_in_pkt() is called with the wrb_params argument being NULLat be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULLpointer when processing a workaround for specific packet, as commitbc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6packet") states.The correct way would be to pass the wrb_params from be_xmit().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40269 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential overflow of PCM transfer bufferThe PCM stream data in USB-audio driver is transferred over USB URBpacket buffers, and each packet size is determined dynamically. Thepacket sizes are limited by some factors such as wMaxPacketSize USBdescriptor. OTOH, in the current code, the actually used packet sizesare determined only by the rate and the PPS, which may be bigger thanthe size limit above. This results in a buffer overflow, as reportedby syzbot.Basically when the limit is smaller than the calculated packet size,it implies that something is wrong, most likely a weird USBdescriptor. So the best option would be just to return an error atthe parameter setup time before doing any further operations.This patch introduces such a sanity check, and returns -EINVAL whenthe packet size is greater than maxpacksize. The comparison withep->packsize[1] alone should suffice since it's always equal orgreater than ep->packsize[0].

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40272 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/secretmem: fix use-after-free race in fault handlerWhen a page fault occurs in a secret memory file created with`memfd_secret(2)`, the kernel will allocate a new folio for it, mark theunderlying page as not-present in the direct map, and add it to the filemapping.If two tasks cause a fault in the same page concurrently, both could endup allocating a folio and removing the page from the direct map, but onlyone would succeed in adding the folio to the file mapping. The task thatfailed undoes the effects of its attempt by (a) freeing the folio againand (b) putting the page back into the direct map. However, by doingthese two operations in this order, the page becomes available to theallocator again before it is placed back in the direct mapping.If another task attempts to allocate the page between (a) and (b), and thekernel tries to access it via the direct map, it would result in asupervisor not-present page fault.Fix the ordering to restore the direct map before the folio is freed.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40273 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: free copynotify stateid in nfs4_free_ol_stateid()Typically copynotify stateid is freed either when parent's stateidis being close/freed or in nfsd4_laundromat if the stateid hasn'tbeen used in a lease period.However, in case when the server got an OPEN (which createda parent stateid), followed by a COPY_NOTIFY using that stateid,followed by a client reboot. New client instance while doingCREATE_SESSION would force expire previous state of this client.It leads to the open state being freed thru release_openowner->nfs4_free_ol_stateid() and it finds that it still has copynotifystateid associated with it. We currently print a warning and istriggerredWARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]This patch, instead, frees the associated copynotify stateid here.If the parent stateid is freed (without freeing the copynotifystateids associated with it), it leads to the list corruptionwhen laundromat ends up freeing the copynotify state later.[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP[ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink[ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary)[ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN[ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024[ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd][ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)[ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200[ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200[ 1626.861182] sp : ffff8000881d7a40[ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200[ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20[ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8[ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000[ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065[ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3[ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000[ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001[ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000[ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d[ 1626.868167] Call trace:[ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P)[ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd][ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd][ 1626.869813] laundromat_main+0x24/0x60 [nfsd][ 1626.870231] process_one_work+0x584/0x1050[ 1626.870595] worker_thread+0x4c4/0xc60[ 1626.870893] kthread+0x2f8/0x398[ 1626.871146] ret_from_fork+0x10/0x20[ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000)[ 1626.871892] SMP: stopping secondary CPUs

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40274 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: guest_memfd: Remove bindings on memslot deletion when gmem is dyingWhen unbinding a memslot from a guest_memfd instance, remove the bindingseven if the guest_memfd file is dying, i.e. even if its file refcount hasgone to zero. If the memslot is freed before the file is fully released,nullifying the memslot side of the binding in kvm_gmem_release() willwrite to freed memory, as detected by syzbot+KASAN: ================================================================== BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x176/0x440 virt/kvm/guest_memfd.c:353 Write of size 8 at addr ffff88807befa508 by task syz.0.17/6022 CPU: 0 UID: 0 PID: 6022 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 kvm_gmem_release+0x176/0x440 virt/kvm/guest_memfd.c:353 __fput+0x44c/0xa70 fs/file_table.c:468 task_work_run+0x1d4/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xe9/0x130 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x2bd/0xfa0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fbeeff8efc9 Allocated by task 6023: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:397 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:414 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x3e2/0x700 mm/slub.c:5758 kmalloc_noprof include/linux/slab.h:957 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] kvm_set_memory_region+0x747/0xb90 virt/kvm/kvm_main.c:2104 kvm_vm_ioctl_set_memory_region+0x6f/0xd0 virt/kvm/kvm_main.c:2154 kvm_vm_ioctl+0x957/0xc60 virt/kvm/kvm_main.c:5201 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6023: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:252 [inline] __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:284 kasan_slab_free include/linux/kasan.h:234 [inline] slab_free_hook mm/slub.c:2533 [inline] slab_free mm/slub.c:6622 [inline] kfree+0x19a/0x6d0 mm/slub.c:6829 kvm_set_memory_region+0x9c4/0xb90 virt/kvm/kvm_main.c:2130 kvm_vm_ioctl_set_memory_region+0x6f/0xd0 virt/kvm/kvm_main.c:2154 kvm_vm_ioctl+0x957/0xc60 virt/kvm/kvm_main.c:5201 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fDeliberately don't acquire filemap invalid lock when the file is dying asthe lifecycle of f_mapping is outside the purview of KVM. Dereferencingthe mapping is *probably* fine, but there's no need to invalidate anythingas memslot deletion is responsible for zapping SPTEs, and the only codethat can access the dying file is kvm_gmem_release(), whose core code ismutual---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40275 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_baddIn snd_usb_create_streams(), for UAC version 3 devices, the InterfaceAssociation Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If thiscall fails, a fallback routine attempts to obtain the IAD from the nextinterface and sets a BADD profile. However, snd_usb_mixer_controls_badd()assumes that the IAD retrieved from usb_ifnum_to_if() is always valid,without performing a NULL check. This can lead to a NULL pointerdereference when usb_ifnum_to_if() fails to find the interface descriptor.This patch adds a NULL pointer check after calling usb_ifnum_to_if() insnd_usb_mixer_controls_badd() to prevent the dereference.This issue was discovered by syzkaller, which triggered the bug by sendinga crafted USB device descriptor.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40276 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Flush shmem writes before mapping buffers CPU-uncachedThe shmem layer zeroes out the new pages using cached mappings, and ifwe don't CPU-flush we might leave dirty cachelines behind, leading topotential data leaks and/or asynchronous buffer corruption when dirtycachelines are evicted.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40277 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZEThis data originates from userspace and is used in buffer offsetcalculations which could potentially overflow causing an out-of-boundsaccess.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40278 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleakFix a KMSAN kernel-infoleak detected by the syzbot .[net?] KMSAN: kernel-infoleak in __skb_datagram_iterIn tcf_ife_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.This change silences the KMSAN report and prevents potential informationleaks from the kernel memory.This fix has been tested and validated by syzbot. This patch closes thebug reported at the following syzkaller link and ensures no infoleak.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40286 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb/server: fix possible memory leak in smb2_read()Memory leak occurs when ksmbd_vfs_read() fails.Fix this by adding the missing kvfree().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40287 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix improper check of dentry.stream.valid_sizeWe found an infinite loop bug in the exFAT file system that can lead to aDenial-of-Service (DoS) condition. When a dentry in an exFAT filesystem ismalformed, the following system calls - SYS_openat, SYS_ftruncate, andSYS_pwrite64 - can cause the kernel to hang.Root cause analysis shows that the size validation code in exfat_find()does not check whether dentry.stream.valid_size is negative. As a result,the system calls mentioned above can succeed and eventually trigger the DoSissue.This patch adds a check for negative dentry.stream.valid_size to preventthis vulnerability.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40288 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devicesPreviously, APU platforms (and other scenarios with uninitialized VRAM managers)triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The rootcause is not that the `struct ttm_resource_manager *man` pointer itself is NULL,but that `man->bdev` (the backing device pointer within the manager) remainsuninitialized (NULL) on APUs-since APUs lack dedicated VRAM and do not fullyset up VRAM manager structures. When `ttm_resource_manager_usage()` attempts toacquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading toa kernel OOPS.1. **amdgpu_cs.c**: Extend the existing bandwidth control check in `amdgpu_cs_get_threshold_for_moves()` to include a check for `ttm_resource_manager_used()`. If the manager is not used (uninitialized `bdev`), return 0 for migration thresholds immediately-skipping VRAM-specific logic that would trigger the NULL dereference.2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info reporting to use a conditional: if the manager is used, return the real VRAM usage; otherwise, return 0. This avoids accessing `man->bdev` when it is NULL.3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function) data write path. Use `ttm_resource_manager_used()` to check validity: if the manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set `fb_usage` to 0 (APUs have no discrete framebuffer to report).This approach is more robust than APU-specific checks because it:- Works for all scenarios where the VRAM manager is uninitialized (not just APUs),- Aligns with TTM's design by using its native helper function,- Preserves correct behavior for discrete GPUs (which have fully initialized `man->bdev` and pass the `ttm_resource_manager_used()` check).v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40289 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAMOtherwise accessing them can cause a crash.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40304 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-boundsAdd bounds checking to prevent writes past framebuffer boundaries whenrendering text near screen edges. Return early if the Y position is off-screenand clip image height to screen boundary. Break from the rendering loop if theX position is off-screen. When clipping image width to fit the screen, updatethe character count to match the clipped width to prevent buffer sizemismatches.Without the character count update, bit_putcs_aligned and bit_putcs_unalignedreceive mismatched parameters where the buffer is allocated for the clippedwidth but cnt reflects the original larger count, causing out-of-bounds writes.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40307 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: validate cluster allocation bits of the allocation bitmapsyzbot created an exfat image with cluster bits not set for the allocationbitmap. exfat-fs reads and uses the allocation bitmap without checkingthis. The problem is that if the start cluster of the allocation bitmapis 6, cluster 6 can be allocated when creating a directory with mkdir.exfat zeros out this cluster in exfat_mkdir, which can delete existingentries. This can reallocate the allocated entries. In addition,the allocation bitmap is also zeroed out, so cluster 6 can be reallocated.This patch adds exfat_test_bitmap_range to validate that clusters used forthe allocation bitmap are correctly marked as in-use.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40308 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: bcsp: receive data only if registeredCurrently, bcsp_recv() can be called even when the BCSP protocol has notbeen registered. This leads to a NULL pointer dereference, as shown inthe following stack trace: KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590 Call Trace: hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627 tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290 tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/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/0x7fTo prevent this, ensure that the HCI_UART_REGISTERED flag is set beforeprocessing received data. If the protocol is not registered, return-EUNATCH.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40310 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_swThere is race in amdgpu_amdkfd_device_fini_sw and interrupt.if amdgpu_amdkfd_device_fini_sw run in b/w kfd_cleanup_nodes and kfree(kfd), and KGD interrupt generated.kernel panic log:BUG: kernel NULL pointer dereference, address: 0000000000000098amdgpu 0000:c8:00.0: amdgpu: Requesting 4 partitions through PSPPGD d78c68067 P4D d78c68067kfd kfd: amdgpu: Allocated 3969056 bytes on gartPUD 1465b8067 PMD @Oops: @002 [#1] SMP NOPTIkfd kfd: amdgpu: Total number of KFD nodes to be created: 4CPU: 115 PID: @ Comm: swapper/115 Kdump: loaded Tainted: G S W OE KRIP: 0010:_raw_spin_lock_irqsave+0x12/0x40Code: 89 e@ 41 5c c3 cc cc cc cc 66 66 2e Of 1f 84 00 00 00 00 00 OF 1f 40 00 Of 1f 44% 00 00 41 54 9c 41 5c fa 31 cO ba 01 00 00 00 OF b1 17 75 Ba 4c 89 e@ 41 Sc89 c6 e8 07 38 5dRSP: 0018: ffffc90@1a6b0e28 EFLAGS: 00010046RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000000000180000000000000001 RSI: ffff8883bb623e00 RDI: 0000000000000098ffff8883bb000000 RO8: ffff888100055020 ROO: ffff8881000550200000000000000000 R11: 0000000000000000 R12: 0900000000000002ffff888F2b97da0@ R14: @000000000000098 R15: ffff8883babdfo00CS: 010 DS: 0000 ES: 0000 CRO: 0000000080050033CR2: 0000000000000098 CR3: 0000000e7cae2006 CR4: 0000000002770ce00000000000000000 DR1: 0000000000000000 DR2: 00000000000000000000000000000000 DR6: 00000000fffeO7FO DR7: 0000000000000400PKRU: 55555554Call Trace:kgd2kfd_interrupt+@x6b/0x1f@ [amdgpu]? amdgpu_fence_process+0xa4/0x150 [amdgpu]kfd kfd: amdgpu: Node: 0, interrupt_bitmap: 3 YcpxFl Rant tEraceamdgpu_irq_dispatch+0x165/0x210 [amdgpu]amdgpu_ih_process+0x80/0x100 [amdgpu]amdgpu: Virtual CRAT table created for GPUamdgpu_irq_handler+0x1f/@x60 [amdgpu]__handle_irq_event_percpu+0x3d/0x170amdgpu: Topology: Add dGPU node [0x74a2:0x1002]handle_irq_event+0x5a/@xcOhandle_edge_irq+0x93/0x240kfd kfd: amdgpu: KFD node 1 partition @ size 49148Masm_call_irq_on_stack+0xf/@x20common_interrupt+0xb3/0x130asm_common_interrupt+0x1le/0x405.10.134-010.a1i5000.a18.x86_64 #1

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40315 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_fs: Fix epfile null pointer access after ep enable.A race condition occurs when ffs_func_eps_enable() runs concurrentlywith ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset()sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leadingto a NULL pointer dereference when accessing epfile->ep inffs_func_eps_enable() after successful usb_ep_enable().The ffs->epfiles pointer is set to NULL in both ffs_data_clear() andffs_data_close() functions, and its modification is protected by thespinlock ffs->eps_lock. And the whole ffs_func_eps_enable() functionis also protected by ffs->eps_lock.Thus, add NULL pointer handling for ffs->epfiles in theffs_func_eps_enable() function to fix issues

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40316 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Fix device use-after-free on unbindA recent change fixed device reference leaks when looking up drmplatform device driver data during bind() but failed to remove a partialfix which had been added by commit 80805b62ea5b ("drm/mediatek: Fixkobject put for component sub-drivers").This results in a reference imbalance on component bind() failures andon unbind() which could lead to a user-after-free.Make sure to only drop the references after retrieving the driver databy effectively reverting the previous partial fix.Note that holding a reference to a device does not prevent its driverdata from going away so there is no point in keeping the reference.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40317 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:regmap: slimbus: fix bus_context pointer in regmap init callsCommit 4e65bda8273c ("ASoC: wcd934x: fix error handling inwcd934x_codec_parse_data()") revealed the problem in the slimbus regmap.That commit breaks audio playback, for instance, on sdm845 ThundercommDragonboard 845c board: Unable to handle kernel paging request at virtual address ffff8000847cbad4 ... CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT Hardware name: Thundercomm Dragonboard 845c (DT) ... Call trace: slim_xfer_msg+0x24/0x1ac [slimbus] (P) slim_read+0x48/0x74 [slimbus] regmap_slimbus_read+0x18/0x24 [regmap_slimbus] _regmap_raw_read+0xe8/0x174 _regmap_bus_read+0x44/0x80 _regmap_read+0x60/0xd8 _regmap_update_bits+0xf4/0x140 _regmap_select_page+0xa8/0x124 _regmap_raw_write_impl+0x3b8/0x65c _regmap_bus_raw_write+0x60/0x80 _regmap_write+0x58/0xc0 regmap_write+0x4c/0x80 wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x] snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core] __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core] dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core] dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core] snd_pcm_hw_params+0x124/0x464 [snd_pcm] snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm] snd_pcm_ioctl+0x34/0x4c [snd_pcm] __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xec el0t_64_sync_handler+0xa0/0xf0 el0t_64_sync+0x198/0x19cThe __devm_regmap_init_slimbus() started to be used instead of__regmap_init_slimbus() after the commit mentioned above and turns outthe incorrect bus_context pointer (3rd argument) was used in__devm_regmap_init_slimbus(). It should be just "slimbus" (which is equalto &slimbus->dev). Correct it. The wcd934x codec seems to be the only orthe first user of devm_regmap_init_slimbus() but we should fix it tillthe point where __devm_regmap_init_slimbus() was introduced thereforetwo "Fixes" tags.While at this, also correct the same argument in __regmap_init_slimbus().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40318 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_oncehci_cmd_sync_dequeue_once() does lookup and then cancelthe entry under two separate lock sections. Meanwhile,hci_cmd_sync_work() can also delete the same entry,leading to double list_del() and "UAF".Fix this by holding cmd_sync_work_lock across bothlookup and cancel, so that the entry cannot be removedconcurrently.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40319 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Sync pending IRQ work before freeing ring bufferFix a race where irq_work can be queued in bpf_ringbuf_commit()but the ring buffer is freed before the work executes.In the syzbot reproducer, a BPF program attached to sched_switchtriggers bpf_ringbuf_commit(), queuing an irq_work. If the ring bufferis freed before this work executes, the irq_work thread may accessesfreed memory.Calling `irq_work_sync(&rb->work)` ensures that all pending irq_workcomplete before freeing the buffer.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40320 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential cfid UAF in smb2_query_info_compoundWhen smb2_query_info_compound() retries, a previously allocated cfid mayhave been freed in the first attempt.Because cfid wasn't reset on replay, later cleanup could act on a stalepointer, leading to a potential use-after-free.Reinitialize cfid to NULL under the replay label.Example trace (trimmed):refcount_t: underflow; use-after-free.WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110[...]RIP: 0010:refcount_warn_saturate+0x9c/0x110[...]Call Trace: smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40321 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix crash while sending Action Frames in standalone AP ModeCurrently, whenever there is a need to transmit an Action frame,the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR tofirmware. The P2P interfaces were available when wpa_supplicant is managingthe wlan interface.However, the P2P interfaces are not created/initialized when only hostapdis managing the wlan interface. And if hostapd receives an ANQP Query REQAction frame even from an un-associated STA, the brcmfmac driver triesto use an uninitialized P2P vif pointer for sending the IOVAR to firmware.This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)Fix this, by always using the vif corresponding to the wdev on which theAction frame Transmission request was initiated by the userspace. This way,even if P2P vif is not available, the IOVAR is sent to firmware on AP vifand the ANQP Query RESP Action frame is transmitted without crashing thedriver.Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev()to brcmf_p2p_attach(). Because the former function would not get executedwhen only hostapd is managing wlan interface, and it is not safe to doreinit_completion() later in brcmf_p2p_tx_action_frame(), without any priorinit_completion().And in the brcmf_p2p_tx_action_frame() function, the condition check forP2P Presence response frame is not needed, since the wpa_supplicant isproperly sending the P2P Presense Response frame on the P2P-GO vif insteadof the P2P-Device vif.[Cc stable]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40324 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Fix crash in nfsd4_read_release()When tracing is enabled, the trace_nfsd_read_done trace pointcrashes during the pynfs read.testNoFh test.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40328 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in smb2_close_cached_fid()find_or_create_cached_dir() could grab a new reference after kref_put()had seen the refcount drop to zero but before cfid_list_lock is acquiredin smb2_close_cached_fid(), leading to use-after-free.Switch to kref_put_lock() so cfid_release() is called withcfid_list_lock held, closing that gap.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40329 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cbThe Mesa issue referenced below pointed out a possible deadlock:[ 1231.611031] Possible interrupt unsafe locking scenario:[ 1231.611033] CPU0 CPU1[ 1231.611034] ---- ----[ 1231.611035] lock(&xa->xa_lock#17);[ 1231.611038] local_irq_disable();[ 1231.611039] lock(&fence->lock);[ 1231.611041] lock(&xa->xa_lock#17);[ 1231.611044] [ 1231.611045] lock(&fence->lock);[ 1231.611047] *** DEADLOCK ***In this example, CPU0 would be any function accessing job->dependenciesthrough the xa_* functions that don't disable interrupts (eg:drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signallingcallback so in an interrupt context. It will deadlock when trying tograb the xa_lock which is already held by CPU0.Replacing all xa_* usage by their xa_*_irq counterparts would fixthis issue, but Christian pointed out another issue: dma_fence_signaltakes fence.lock and so does dma_fence_add_callback. dma_fence_signal() // locks f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // locks f2.lockThis will deadlock if f1 and f2 share the same spinlock.To fix both issues, the code iterating on dependencies and re-arming themis moved out to drm_sched_entity_kill_jobs_work().[phasta: commit message nits]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40330 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Shutdown FW DMA in bnxt_shutdown()The netif_close() call in bnxt_shutdown() only stops packet DMA. Theremay be FW DMA for trace logging (recently added) that will continue. Ifwe kexec to a new kernel, the DMA will corrupt memory in the new kernel.Add bnxt_hwrm_func_drv_unrgtr() to unregister the driver from the FW.This will stop the FW DMA. In case the call fails, call pcie_flr() toreset the function and stop the DMA.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40331 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Prevent TOCTOU out-of-bounds writeFor the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()make sure not to exceed bounds in case the address list has grownbetween buffer allocation (time-of-check) and write (time-of-use).

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40332 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix mmap write lock not releaseIf mmap write lock is taken while draining retry fault, mmap write lockis not released because svm_range_restore_pages calls mmap_read_unlockthen returns. This causes deadlock and system hangs later because mmapread or write lock cannot be taken.Downgrade mmap write lock to read lock if draining retry fault fix thisbug.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40337 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: Correctly handle Rx checksum offload errorsThe stmmac_rx function would previously set skb->ip_summed toCHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabledand the packet was of a known IP ethertype.However, this logic failed to check if the hardware had actuallyreported a checksum error. The hardware status, indicating a header orpayload checksum failure, was being ignored at this stage. This couldcause corrupt packets to be passed up the network stack as valid.This patch corrects the logic by checking the `csum_none` status flag,which is set when the hardware reports a checksum error. If this flagis set, skb->ip_summed is now correctly set to CHECKSUM_NONE,ensuring the kernel's network stack will perform its own validation andproperly handle the corrupt packet.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40341 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:futex: Don't leak robust_list pointer on exec racesys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()to check if the calling task is allowed to access another task'srobust_list pointer. This check is racy against a concurrent exec() in thetarget process.During exec(), a task may transition from a non-privileged binary to aprivileged one (e.g., setuid binary) and its credentials/memory mappingsmay change. If get_robust_list() performs ptrace_may_access() beforethis transition, it may erroneously allow access to sensitive informationafter the target becomes privileged.A racy access allows an attacker to exploit a window during whichptrace_may_access() passes before a target process transitions to aprivileged state via exec().For example, consider a non-privileged task T that is about to execute asetuid-root binary. An attacker task A calls get_robust_list(T) while Tis still unprivileged. Since ptrace_may_access() checks permissionsbased on current credentials, it succeeds. However, if T begins execimmediately afterwards, it becomes privileged and may change its memorymappings. Because get_robust_list() proceeds to access T->robust_listwithout synchronizing with exec() it may read user-space pointers from anow-privileged process.This violates the intended post-exec access restrictions and couldexpose sensitive memory addresses or be used as a primitive in a largerexploit chain. Consequently, the race can lead to unauthorizeddisclosure of information across privilege boundaries and poses apotential security risk.Take a read lock on signal->exec_update_lock prior to invokingptrace_may_access() and accessing the robust_list/compat_robust_list.This ensures that the target task's exec state remains stable during thecheck, allowing for consistent and synchronized validation ofcredentials.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40344 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: avs: Disable periods-elapsed work when closing PCMavs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudiostream while period-elapsed work services its IRQs. As the formerfrees the DAI's private context, these two operations shall besynchronized to avoid slab-use-after-free or worse errors.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40346 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()which causes the code to proceed with NULL clock pointers. The currentlogic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for bothvalid pointers and NULL, leading to potential NULL pointer dereferencein clk_get_rate().Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:"The error code within @ptr if it is an error pointer; 0 otherwise."This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULLpointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to becalled when of_clk_get() returns NULL.Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for validpointers, preventing potential NULL pointer dereference in clk_get_rate().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40347 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: fix the deadlock of enetc_mdio_lockAfter applying the workaround for err050089, the LS1028A platformexperiences RCU stalls on RT kernel. This issue is caused by therecursive acquisition of the read lock enetc_mdio_lock. Here list someof the call stacks identified under the enetc_poll path that may lead toa deadlock:enetc_poll -> enetc_lock_mdio -> enetc_clean_rx_ring OR napi_complete_done -> napi_gro_receive -> enetc_start_xmit -> enetc_lock_mdio -> enetc_map_tx_buffs -> enetc_unlock_mdio -> enetc_unlock_mdioAfter enetc_poll acquires the read lock, a higher-priority writer attemptsto acquire the lock, causing preemption. The writer detects that aread lock is already held and is scheduled out. However, readers underenetc_poll cannot acquire the read lock again because a writer is alreadywaiting, leading to a thread hang.Currently, the deadlock is avoided by adjusting enetc_lock_mdio to preventrecursive lock acquisition.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40350 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQXDP programs can change the layout of an xdp_buff throughbpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the drivercannot assume the size of the linear data area nor fragments. Fix thebug in mlx5 by generating skb according to xdp_buff after XDP programsrun.Currently, when handling multi-buf XDP, the mlx5 driver assumes thelayout of an xdp_buff to be unchanged. That is, the linear data areacontinues to be empty and fragments remain the same. This may causethe driver to generate erroneous skb or triggering a kernelwarning. When an XDP program added linear data throughbpf_xdp_adjust_head(), the linear data will be ignored asmlx5e_build_linear_skb() builds an skb without linear data and thenpull data from fragments to fill the linear data area. When an XDPprogram has shrunk the non-linear data through bpf_xdp_adjust_tail(),the delta passed to __pskb_pull_tail() may exceed the actual nonlineardata size and trigger the BUG_ON in it.To fix the issue, first record the original number of fragments. If thenumber of fragments changes after the XDP program runs, rewind the endfragment pointer by the difference and recalculate the truesize. Then,build the skb with the linear data area matching the xdp_buff. Finally,only pull data in if there is non-linear data and fill the linear partup to 256 bytes.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40354 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: increase max link count and fix link->enc NULL pointer access[why]1.) dc->links[MAX_LINKS] array size smaller than actual requested.max_connector + max_dpia + 4 virtual = 14.increase from 12 to 14.2.) hw_init() access null LINK_ENC for dpia non display_endpoint.(cherry picked from commit d7f5a61e1b04ed87b008c8d327649d184dc5bb45)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40355 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sysfs: check visibility before changing group attribute ownershipSince commit 0c17270f9b92 ("net: sysfs: Implement is_visible forphys_(port_id, port_name, switch_id)"), __dev_change_net_namespace() canhit WARN_ON() when trying to change owner of a file that isn't visible.See the trace below: WARNING: CPU: 6 PID: 2938 at net/core/dev.c:12410 __dev_change_net_namespace+0xb89/0xc30 CPU: 6 UID: 0 PID: 2938 Comm: incusd Not tainted 6.17.1-1-mainline #1 PREEMPT(full) 4b783b4a638669fb644857f484487d17cb45ed1f Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, BIOS 03.07 02/19/2025 RIP: 0010:__dev_change_net_namespace+0xb89/0xc30 [...] Call Trace: ? if6_seq_show+0x30/0x50 do_setlink.isra.0+0xc7/0x1270 ? __nla_validate_parse+0x5c/0xcc0 ? security_capable+0x94/0x1a0 rtnl_newlink+0x858/0xc20 ? update_curr+0x8e/0x1c0 ? update_entity_lag+0x71/0x80 ? sched_balance_newidle+0x358/0x450 ? psi_task_switch+0x113/0x2a0 ? __pfx_rtnl_newlink+0x10/0x10 rtnetlink_rcv_msg+0x346/0x3e0 ? sched_clock+0x10/0x30 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 netlink_rcv_skb+0x59/0x110 netlink_unicast+0x285/0x3c0 ? __alloc_skb+0xdb/0x1a0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x39f/0x3d0 ? import_iovec+0x2f/0x40 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x81/0x970 ? __sys_bind+0xe3/0x110 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? sock_alloc_file+0x63/0xc0 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? alloc_fd+0x12e/0x190 ? put_unused_fd+0x2a/0x70 ? do_sys_openat2+0xa2/0xe0 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Fix this by checking is_visible() before trying to touch the attribute.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40360 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sysfb: Do not dereference NULL pointer in plane resetThe plane state in __drm_gem_reset_shadow_plane() can be NULL. Do notderef that pointer, but forward NULL to the other plane-reset helpers.Clears plane->state to NULL.v2:- fix typo in commit description (Javier)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-54409 Severity: Moderate CVSS3 score: 5.5

Description: AIDE is an advanced intrusion detection environment. From versions 0.13 to 0.19.1, there is a null pointer dereference vulnerability in AIDE. An attacker can crash the program during report printing or database listing after setting extended file attributes with an empty attribute value or with a key containing a comma. A local user might exploit this to cause a local denial of service. This issue has been patched in version 0.19.2. A workaround involves removing xattrs group from rules matching files on affected file systems.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
aide > 0-0 (version in image is 0.18.8-160000.2.2).

CVE-2025-68167 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gpiolib: fix invalid pointer access in debugfsIf the memory allocation in gpiolib_seq_start() fails, the s->privatefield remains uninitialized and is later dereferenced without checkingin gpiolib_seq_stop(). Initialize s->private to NULL before callingkzalloc() and check it before dereferencing it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68170 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: Do not kfree() devres managed rdevSince the allocation of the drivers main structure was changed todevm_drm_dev_alloc() rdev is managed by devres and we shouldn't be callingkfree() on it.This fixes things exploding if the driver probe fails and devres cleans upthe rdev after we already free'd it.(cherry picked from commit 16c0681617b8a045773d4d87b6140002fa75b03b)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68171 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Ensure XFD state on signal deliverySean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53Chao further identified [2] a reproducible scenario involving signaldelivery: a non-AMX task is preempted by an AMX-enabled task whichmodifies the XFD MSR.When the non-AMX task resumes and reloads XSTATE with init values,a warning is triggered due to a mismatch between fpstate::xfd and theCPU's current XFD state. fpu__clear_user_states() does not currentlyre-synchronize the XFD state after such preemption.Invoke xfd_update_state() which detects and corrects the mismatch ifthere is a dynamic feature.This also benefits the sigreturn path, as fpu__restore_sig() may callfpu__clear_user_states() when the sigframe is inaccessible.[ dhansen: minor changelog munging ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68172 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: aspeed - fix double free caused by devmThe clock obtained via devm_clk_get_enabled() is automatically managedby devres and will be disabled and freed on driver detach. Manuallycalling clk_disable_unprepare() in error path and remove functioncauses double free.Remove the manual clock cleanup in both aspeed_acry_probe()'s errorpath and aspeed_acry_remove().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68173 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix softlockup in ftrace_module_enableA soft lockup was observed when loading amdgpu module.If a module has a lot of tracable functions, multiple callsto kallsyms_lookup can spend too much time in RCU criticalsection and with disabled preemption, causing kernel panic.This is the same issue that was fixed incommit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARYkernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() toftrace_graph_set_hash()").Fix it the same way by adding cond_resched() in ftrace_module_enable.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68174 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:amd/amdkfd: enhance kfd process check in switch partitioncurrent switch partition only check if kfd_processes_table is empty.kfd_prcesses_table entry is deleted in kfd_process_notifier_release, butkfd_process tear down is in kfd_process_wq_release.consider two processes:Process A (workqueue) -> kfd_process_wq_release -> Access kfd_node memberProcess B switch partition -> amdgpu_xcp_pre_partition_switch -> amdgpu_amdkfd_device_fini_sw-> kfd_node tear down.Process A and B may trigger a race as shown in dmesg log.This patch is to resolve the race by adding an atomic kfd_process counterkfd_processes_count, it increment as create kfd process, decrement asfinish kfd_process_wq_release.v2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pddsand bug fix. (Philip Yang)[3966658.307702] divide error: 0000 [#1] SMP NOPTI[3966658.350818] i10nm_edac[3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted[3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu][3966658.362839] nfit[3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu][3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00[3966658.380967] x86_pkg_temp_thermal[3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246[3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000[3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00[3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4[3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000[3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800[3966658.391533] FS: 0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000[3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0[3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[3966658.391536] PKRU: 55555554[3966658.391536] Call Trace:[3966658.391674] deallocate_sdma_queue+0x38/0xa0 [amdgpu][3966658.391762] process_termination_cpsch+0x1ed/0x480 [amdgpu][3966658.399754] intel_powerclamp[3966658.402831] kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu][3966658.402908] kfd_process_wq_release+0x1a/0x1a0 [amdgpu][3966658.410516] coretemp[3966658.434016] process_one_work+0x1ad/0x380[3966658.434021] worker_thread+0x49/0x310[3966658.438963] kvm_intel[3966658.446041] ? process_one_work+0x380/0x380[3966658.446045] kthread+0x118/0x140[3966658.446047] ? __kthread_bind_mask+0x60/0x60[3966658.446050] ret_from_fork+0x1f/0x30[3966658.446053] Modules linked in: kpatch_20765354(OEK)[3966658.455310] kvm[3966658.464534] mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK)[3966658.473462] idxd_mdev[3966658.482306] kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68175 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: nxp: imx8-isi: Fix streaming cleanup on releaseThe current implementation unconditionally callsmxc_isi_video_cleanup_streaming() in mxc_isi_video_release(). This canlead to situations where any release call (like from a simple"v4l2-ctl -l") may release a currently streaming queue when called onsuch a device.This is reproducible on an i.MX8MP board by streaming from an ISIcapture device using gstreamer: gst-launch-1.0 -v v4l2src device=/dev/videoX ! \ video/x-raw,format=GRAY8,width=1280,height=800,framerate=1/120 ! \ fakesinkWhile this stream is running, querying the caps of the same deviceprovokes the error state: v4l2-ctl -l -d /dev/videoXThis results in the following trace:[ 155.452152] ------------[ cut here ]------------[ 155.452163] WARNING: CPU: 0 PID: 1708 at drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c:713 mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi][ 157.004248] Modules linked in: cfg80211 rpmsg_ctrl rpmsg_char rpmsg_tty virtio_rpmsg_bus rpmsg_ns rpmsg_core rfkill nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables mcp251x6[ 157.053499] CPU: 0 UID: 0 PID: 1708 Comm: python3 Not tainted 6.15.4-00114-g1f61ca5cad76 #1 PREEMPT[ 157.064369] Hardware name: imx8mp_board_01 (DT)[ 157.068205] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 157.075169] pc : mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi][ 157.081195] lr : mxc_isi_pipe_irq_handler+0x38/0x1b0 [imx8_isi][ 157.087126] sp : ffff800080003ee0[ 157.090438] x29: ffff800080003ee0 x28: ffff0000c3688000 x27: 0000000000000000[ 157.097580] x26: 0000000000000000 x25: ffff0000c1e7ac00 x24: ffff800081b5ad50[ 157.104723] x23: 00000000000000d1 x22: 0000000000000000 x21: ffff0000c25e4000[ 157.111866] x20: 0000000060000200 x19: ffff80007a0608d0 x18: 0000000000000000[ 157.119008] x17: ffff80006a4e3000 x16: ffff800080000000 x15: 0000000000000000[ 157.126146] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000[ 157.133287] x11: 0000000000000040 x10: ffff0000c01445f0 x9 : ffff80007a053a38[ 157.140425] x8 : ffff0000c04004b8 x7 : 0000000000000000 x6 : 0000000000000000[ 157.147567] x5 : ffff0000c0400490 x4 : ffff80006a4e3000 x3 : ffff0000c25e4000[ 157.154706] x2 : 0000000000000000 x1 : ffff8000825c0014 x0 : 0000000060000200[ 157.161850] Call trace:[ 157.164296] mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi] (P)[ 157.170319] __handle_irq_event_percpu+0x58/0x218[ 157.175029] handle_irq_event+0x54/0xb8[ 157.178867] handle_fasteoi_irq+0xac/0x248[ 157.182968] handle_irq_desc+0x48/0x68[ 157.186723] generic_handle_domain_irq+0x24/0x38[ 157.191346] gic_handle_irq+0x54/0x120[ 157.195098] call_on_irq_stack+0x24/0x30[ 157.199027] do_interrupt_handler+0x88/0x98[ 157.203212] el0_interrupt+0x44/0xc0[ 157.206792] __el0_irq_handler_common+0x18/0x28[ 157.211328] el0t_64_irq_handler+0x10/0x20[ 157.215429] el0t_64_irq+0x198/0x1a0[ 157.219009] ---[ end trace 0000000000000000 ]---Address this issue by moving the streaming preparation and cleanup tothe vb2 .prepare_streaming() and .unprepare_streaming() operations. Thisalso simplifies the driver by allowing direct usage of thevb2_ioctl_streamon() and vb2_ioctl_streamoff() helpers, and removal ofthe manual cleanup from mxc_isi_video_release().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68176 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: cadence: Check for the existence of cdns_pcie::ops before using itcdns_pcie::ops might not be populated by all the Cadence glue drivers. Thisis going to be true for the upcoming Sophgo platform which doesn't set theops.Hence, add a check to prevent NULL pointer dereference.[mani: reworded subject and description]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68178 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: fix possible deadlock while configuring policyFollowing deadlock can be triggered easily by lockdep:WARNING: possible circular locking dependency detected6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted------------------------------------------------------check/1334 is trying to acquire lock:ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180but task is already holding lock:ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #1 (&q->rq_qos_mutex){+.+.}-{4:4}: __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 really_probe+0x136/0x620 __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0 __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30-> #0 (&q->sysfs_lock){+.+.}-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0 __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7eother info that might help us debug this:Chain exists of: &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&q->q_usage_counter(queue)#3); lock(&q->rq_qos_mutex); lock(&q->q_usage_counter(queue)#3); lock(&q->sysfs_lock);Root cause is that queue_usage_counter is grabbed with rq_qos_mutexheld in blkg_conf_prep(), while queue should be freezed beforerq_qos_mutex from other context.The blk_queue_enter() from blkg_conf_prep() is used to protect againstpolicy deactivation, which is already protected with blkcg_mutex, henceconvert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile,consider that blkcg_mutex is held after queue is freezed from policydeactivation, also convert blkg_alloc() to use GFP_NOIO.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68179 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAPAs reported by Luiz Capitulino enabling HVO on s390 leads to reproduciblecrashes. The problem is that kernel page tables are modified withoutflushing corresponding TLB entries.Even if it looks like the empty flush_tlb_all() implementation on s390 isthe problem, it is actually a different problem: on s390 it is not allowedto replace an active/valid page table entry with another valid page tableentry without the detour over an invalid entry. A direct replacement maylead to random crashes and/or data corruption.In order to invalidate an entry special instructions have to be used(e.g. ipte or idte). Alternatively there are also special instructionsavailable which allow to replace a valid entry with a different validentry (e.g. crdte or cspg).Given that the HVO code currently does not provide the hooks to allow foran implementation which is compliant with the s390 architecturerequirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which isbasically a revert of the original patch which enabled it.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68180 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix NULL deref in debugfs odm_combine_segmentsWhen a connector is connected but inactive (e.g., disabled by desktopenvironments), pipe_ctx->stream_res.tg will be destroyed. Then, readingodm_combine_segments causes kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 16 UID: 0 PID: 26474 Comm: cat Not tainted 6.17.0+ #2 PREEMPT(lazy) e6a17af9ee6db7c63e9d90dbe5b28ccab67520c6 Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN25WW 03/27/2025 RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: seq_read_iter+0x125/0x490 ? __alloc_frozen_pages_noprof+0x18f/0x350 seq_read+0x12c/0x170 full_proxy_read+0x51/0x80 vfs_read+0xbc/0x390 ? __handle_mm_fault+0xa46/0xef0 ? do_syscall_64+0x71/0x900 ksys_read+0x73/0xf0 do_syscall_64+0x71/0x900 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 RIP: 0033:0x7f44d4031687 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> RSP: 002b:00007ffdb4b5f0b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007f44d3f9f740 RCX: 00007f44d4031687 RDX: 0000000000040000 RSI: 00007f44d3f5e000 RDI: 0000000000000003 RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007f44d3f5e000 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000040000 Modules linked in: tls tcp_diag inet_diag xt_mark ccm snd_hrtimer snd_seq_dummy snd_seq_midi snd_seq_oss snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device x> snd_hda_codec_atihdmi snd_hda_codec_realtek_lib lenovo_wmi_helpers think_lmi snd_hda_codec_generic snd_hda_codec_hdmi snd_soc_core kvm snd_compress uvcvideo sn> platform_profile joydev amd_pmc mousedev mac_hid sch_fq_codel uinput i2c_dev parport_pc ppdev lp parport nvme_fabrics loop nfnetlink ip_tables x_tables dm_cryp> CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554Fix this by checking pipe_ctx->---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68181 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: Remove calls to drm_put_dev()Since the allocation of the drivers main structure was changed todevm_drm_dev_alloc() drm_put_dev()'ing to trigger it to be free'dshould be done by devres.However, drm_put_dev() is still in the probe error and device removepaths. When the driver fails to probe warnings like the following areshown because devres is trying to drm_put_dev() after the driveralready did it.[ 5.642230] radeon 0000:01:05.0: probe with driver radeon failed with error -22[ 5.649605] ------------[ cut here ]------------[ 5.649607] refcount_t: underflow; use-after-free.[ 5.649620] WARNING: CPU: 0 PID: 357 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110(cherry picked from commit 3eb8c0b4c091da0a623ade0d3ee7aa4a93df1ea4)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68184 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Disable AFBC support on Mediatek DRM driverCommit c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRMdriver") added AFBC support to Mediatek DRM and enabled the32x8/split/sparse modifier.However, this is currently broken on Mediatek MT8188 (Genio 700 EVKplatform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used bydefault since Mesa v25.0.Kernel trace reports vblank timeouts constantly, and the render is garbled:```[CRTC:62:crtc-0] vblank wait timed outWARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c[...]Hardware name: MediaTek Genio-700 EVK (DT)Workqueue: events_unbound commit_workpstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27clr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27csp : ffff80008337bca0x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000ax17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206bx11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480Call trace: drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P) drm_atomic_helper_commit_tail_rpm+0x64/0x80 commit_tail+0xa4/0x1a4 commit_work+0x14/0x20 process_one_work+0x150/0x290 worker_thread+0x2d0/0x3ec kthread+0x12c/0x210 ret_from_fork+0x10/0x20---[ end trace 0000000000000000 ]---```Until this gets fixed upstream, disable AFBC support on this platform, asit's currently broken with upstream Mesa.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68185 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencingTheoretically it's an oopsable race, but I don't believe one can manageto hit it on real hardware; might become doable on a KVM, but it stillwon't be easy to attack.Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call ofput_unaligned_be64(), we can put that under ->d_lock and be done with that.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68186 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Do not warn in ring_buffer_map_get_reader() when reader catches upThe function ring_buffer_map_get_reader() is a bit more strict than theother get reader functions, and except for certain situations therb_get_reader_page() should not return NULL. If it does, it triggers awarning.This warning was triggering but after looking at why, it was becauseanother acceptable situation was happening and it wasn't checked for.If the reader catches up to the writer and there's still data to be readon the reader page, then the rb_get_reader_page() will return NULL asthere's no new page to get.In this situation, the reader page should not be updated and no warningshould trigger.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68190 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()kcalloc() may fail. When WS is non-zero and allocation fails, ectx.wsremains NULL while ectx.ws_size is set, leading to a potential NULLpointer dereference in atom_get_src_int() when accessing WS entries.Return -ENOMEM on allocation failure to avoid the NULL dereference.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68192 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixupRaw IP packets have no MAC header, leaving skb->mac_header uninitialized.This can trigger kernel panics on ARM64 when xfrm or other subsystemsaccess the offset due to strict alignment checks.Initialize the MAC header to prevent such crashes.This can trigger kernel panics on ARM when running IPsec over theqmimux0 interface.Example trace: Internal error: Oops: 000000009600004f [#1] SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1 Hardware name: LS1028A RDB Board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xfrm_input+0xde8/0x1318 lr : xfrm_input+0x61c/0x1318 sp : ffff800080003b20 Call trace: xfrm_input+0xde8/0x1318 xfrm6_rcv+0x38/0x44 xfrm6_esp_rcv+0x48/0xa8 ip6_protocol_deliver_rcu+0x94/0x4b0 ip6_input_finish+0x44/0x70 ip6_input+0x44/0xc0 ipv6_rcv+0x6c/0x114 __netif_receive_skb_one_core+0x5c/0x8c __netif_receive_skb+0x18/0x60 process_backlog+0x78/0x17c __napi_poll+0x38/0x180 net_rx_action+0x168/0x2f0

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68193 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/guc: Add devm release action to safely tear down CTWhen a buffer object (BO) is allocated with the XE_BO_FLAG_GGTT_INVALIDATEflag, the driver initiates TLB invalidation requests via the CTB mechanismwhile releasing the BO. However a premature release of the CTB BO can leadto system crashes, as observed in:Oops: Oops: 0000 [#1] SMP NOPTIRIP: 0010:h2g_write+0x2f3/0x7c0 [xe]Call Trace: guc_ct_send_locked+0x8b/0x670 [xe] xe_guc_ct_send_locked+0x19/0x60 [xe] send_tlb_invalidation+0xb4/0x460 [xe] xe_gt_tlb_invalidation_ggtt+0x15e/0x2e0 [xe] ggtt_invalidate_gt_tlb.part.0+0x16/0x90 [xe] ggtt_node_remove+0x110/0x140 [xe] xe_ggtt_node_remove+0x40/0xa0 [xe] xe_ggtt_remove_bo+0x87/0x250 [xe]Introduce a devm-managed release action during xe_guc_ct_init() andxe_guc_ct_init_post_hwconfig() to ensure proper CTB disablement beforeresource deallocation, preventing the use-after-free scenario.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68194 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imon: make send_packet() more robustsyzbot is reporting that imon has three problems which result inhung tasks due to forever holding device lock [1].First problem is that when usb_rx_callback_intf0() once got -EPROTO errorafter ictx->dev_present_intf0 became true, usb_rx_callback_intf0()resubmits urb after printk(), and resubmitted urb causesusb_rx_callback_intf0() to again get -EPROTO error. This results inprintk() flooding (RCU stalls).Alan Stern commented [2] that In theory it's okay to resubmit _if_ the driver has a robust error-recovery scheme (such as giving up after some fixed limit on the number of errors or after some fixed time has elapsed, perhaps with a time delay to prevent a flood of errors). Most drivers don't bother to do this; they simply give up right away. This makes them more vulnerable to short-term noise interference during USB transfers, but in reality such interference is quite rare. There's nothing really wrong with giving up right away.but imon has a poor error-recovery scheme which just retries forever;this behavior should be fixed.Since I'm not sure whether it is safe for imon users to give up upon anyerror code, this patch takes care of only union of error codes chosen frommodules in drivers/media/rc/ directory which handle -EPROTO error (i.e.ir_toy, mceusb and igorplugusb).Second problem is that when usb_rx_callback_intf0() once got -EPROTO errorbefore ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() alwaysresubmits urb due to commit 8791d63af0cf ("[media] imon: don't wedgehardware after early callbacks"). Move the ictx->dev_present_intf0 testintroduced by commit 6f6b90c9231a ("[media] imon: don't parse scancodesuntil intf configured") to immediately before imon_incoming_packet(), orthe first problem explained above happens without printk() flooding (i.e.hung task).Third problem is that when usb_rx_callback_intf0() is not called for somereason (e.g. flaky hardware; the reproducer for this problem sometimesprevents usb_rx_callback_intf0() from being called),wait_for_completion_interruptible() in send_packet() never returns (i.e.hung task). As a workaround for such situation, change send_packet() towait for completion with timeout of 10 seconds.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68195 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/CPU/AMD: Add missing terminator for zen5_rdseed_microcodeRunning x86_match_min_microcode_rev() on a Zen5 CPU trips up KASAN for an outof bounds access.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68197 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix null pointer dereference in bnxt_bs_trace_check_wrap()With older FW, we may get the ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCERfor FW trace data type that has not been initialized. This will resultin a crash in bnxt_bs_trace_type_wrap(). Add a guard to check for avalid magic_byte pointer before proceeding.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68198 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crash: fix crashkernel resource shrinkWhen crashkernel is configured with a high reservation, shrinking itsvalue below the low crashkernel reservation causes two issues:1. Invalid crashkernel resource objects2. Kernel crash if crashkernel shrinking is done twiceFor example, with crashkernel=200M,high, the kernel reserves 200MB of highmemory and some default low memory (say 256MB). The reservation appearsas:cat /proc/iomem | grep -i crashaf000000-beffffff : Crash kernel433000000-43f7fffff : Crash kernelIf crashkernel is then shrunk to 50MB (echo 52428800 >/sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved:af000000-beffffff : Crash kernelInstead, it should show 50MB:af000000-b21fffff : Crash kernelFurther shrinking crashkernel to 40MB causes a kernel crash with thefollowing trace (x86):BUG: kernel NULL pointer dereference, address: 0000000000000038PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP NOPTICall Trace: ? __die_body.cold+0x19/0x27? page_fault_oops+0x15a/0x2f0? search_module_extables+0x19/0x60? search_bpf_extables+0x5f/0x80? exc_page_fault+0x7e/0x180? asm_exc_page_fault+0x26/0x30? __release_resource+0xd/0xb0release_resource+0x26/0x40__crash_shrink_memory+0xe5/0x110crash_shrink_memory+0x12a/0x190kexec_crash_size_store+0x41/0x80kernfs_fop_write_iter+0x141/0x1f0vfs_write+0x294/0x460ksys_write+0x6d/0xf0This happens because __crash_shrink_memory()/kernel/crash_core.cincorrectly updates the crashk_res resource object even whencrashk_low_res should be updated.Fix this by ensuring the correct crashkernel resource object is updatedwhen shrinking crashkernel memory.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68199 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:codetag: debug: handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_extWhen alloc_slab_obj_exts() fails and then later succeeds in allocating aslab extension vector, it calls handle_failed_objexts_alloc() to mark allobjects in the vector as empty. As a result all objects in this slab(slabA) will have their extensions set to CODETAG_EMPTY.Later on if this slabA is used to allocate a slabobj_ext vector foranother slab (slabB), we end up with the slabB->obj_exts pointing to aslabobj_ext vector that itself has a non-NULL slabobj_ext equal toCODETAG_EMPTY. When slabB gets freed, free_slab_obj_exts() is called tofree slabB->obj_exts vector. free_slab_obj_exts() calls mark_objexts_empty(slabB->obj_exts) which willgenerate a warning because it expects slabobj_ext vectors to have a NULLobj_ext, not CODETAG_EMPTY.Modify mark_objexts_empty() to skip the warning and setting the obj_extvalue if it's already set to CODETAG_EMPTY.To quickly detect this WARN, I modified the code fromWARN_ON(slab_exts[offs].ref.ct) to BUG_ON(slab_exts[offs].ref.ct == 1);We then obtained this message:[21630.898561] ------------[ cut here ]------------[21630.898596] kernel BUG at mm/slub.c:2050![21630.898611] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP[21630.900372] Modules linked in: squashfs isofs vfio_iommu_type1 vhost_vsock vfio vhost_net vmw_vsock_virtio_transport_common vhost tap vhost_iotlb iommufd vsock binfmt_misc nfsv3 nfs_acl nfs lockd grace netfs tls rds dns_resolver tun brd overlay ntfs3 exfat btrfs blake2b_generic xor xor_neon raid6_pq loop sctp ip6_udp_tunnel udp_tunnel nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables rfkill ip_set sunrpc vfat fat joydev sg sch_fq_codel nfnetlink virtio_gpu sr_mod cdrom drm_client_lib virtio_dma_buf drm_shmem_helper drm_kms_helper drm ghash_ce backlight virtio_net virtio_blk virtio_scsi net_failover virtio_console failover virtio_mmio dm_mirror dm_region_hash dm_log dm_multipath dm_mod fuse i2c_dev virtio_pci virtio_pci_legacy_dev virtio_pci_modern_dev virtio virtio_ring autofs4 aes_neon_bs aes_ce_blk [last unloaded: hwpoison_inject][21630.909177] CPU: 3 UID: 0 PID: 3787 Comm: kylin-process-m Kdump: loaded Tainted: G W 6.18.0-rc1+ #74 PREEMPT(voluntary)[21630.910495] Tainted: [W]=WARN[21630.910867] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022[21630.911625] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[21630.912392] pc : __free_slab+0x228/0x250[21630.912868] lr : __free_slab+0x18c/0x250[21630.913334] sp : ffff8000a02f73e0[21630.913830] x29: ffff8000a02f73e0 x28: fffffdffc43fc800 x27: ffff0000c0011c40[21630.914677] x26: ffff0000c000cac0 x25: ffff00010fe5e5f0 x24: ffff000102199b40[21630.915469] x23: 0000000000000003 x22: 0000000000000003 x21: ffff0000c0011c40[21630.916259] x20: fffffdffc4086600 x19: fffffdffc43fc800 x18: 0000000000000000[21630.917048] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000[21630.917837] x14: 0000000000000000 x13: 0000000000000000 x12: ffff70001405ee66[21630.918640] x11: 1ffff0001405ee65 x10: ffff70001405ee65 x9 : ffff800080a295dc[21630.919442] x8 : ffff8000a02f7330 x7 : 0000000000000000 x6 : 0000000000003000[21630.920232] x5 : 0000000024924925 x4 : 0000000000000001 x3 : 0000000000000007[21630.921021] x2 : 0000000000001b40 x1 : 000000000000001f x0 : 0000000000000001[21630.921810] Call trace:[21630.922130] __free_slab+0x228/0x250 (P)[21630.922669] free_slab+0x38/0x118[21630.923079] free_to_partial_list+0x1d4/0x340[21630.923591] __slab_free+0x24c/0x348[21630.924024] ___cache_free+0xf0/0x110[21630.924468] qlist_free_all+0x78/0x130[21630.924922] kasan_quarantine_reduce+0x11---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68200 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Add bpf_prog_run_data_pointers()syzbot found that cls_bpf_classify() is able to changetc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop().WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline]WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched:Extend qdisc control block with tc control block"), which added a wronginteraction with db58ba459202 ("bpf: wire in data and data_end forcls_act_bpf").drop_reason was added later.Add bpf_prog_run_data_pointers() helper to save/restore the net_schedstorage colliding with BPF data_meta/data_end.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68201 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: remove two invalid BUG_ON()sThose can be triggered trivially by userspace.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68202 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched_ext: Fix unsafe locking in the scx_dump_state()For built with CONFIG_PREEMPT_RT=y kernels, the dump_lock will be convertedsleepable spinlock and not disable-irq, so the following scenarios occur:inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.irq_work/0/27 [HC0[0]:SC0[0]:HE1:SE1] takes:(&rq->__lock){?...}-{2:2}, at: raw_spin_rq_lock_nested+0x2b/0x40{IN-HARDIRQ-W} state was registered at: lock_acquire+0x1e1/0x510 _raw_spin_lock_nested+0x42/0x80 raw_spin_rq_lock_nested+0x2b/0x40 sched_tick+0xae/0x7b0 update_process_times+0x14c/0x1b0 tick_periodic+0x62/0x1f0 tick_handle_periodic+0x48/0xf0 timer_interrupt+0x55/0x80 __handle_irq_event_percpu+0x20a/0x5c0 handle_irq_event_percpu+0x18/0xc0 handle_irq_event+0xb5/0x150 handle_level_irq+0x220/0x460 __common_interrupt+0xa2/0x1e0 common_interrupt+0xb0/0xd0 asm_common_interrupt+0x2b/0x40 _raw_spin_unlock_irqrestore+0x45/0x80 __setup_irq+0xc34/0x1a30 request_threaded_irq+0x214/0x2f0 hpet_time_init+0x3e/0x60 x86_late_time_init+0x5b/0xb0 start_kernel+0x308/0x410 x86_64_start_reservations+0x1c/0x30 x86_64_start_kernel+0x96/0xa0 common_startup_64+0x13e/0x148 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&rq->__lock); lock(&rq->__lock); *** DEADLOCK *** stack backtrace: CPU: 0 UID: 0 PID: 27 Comm: irq_work/0 Call Trace: dump_stack_lvl+0x8c/0xd0 dump_stack+0x14/0x20 print_usage_bug+0x42e/0x690 mark_lock.part.44+0x867/0xa70 ? __pfx_mark_lock.part.44+0x10/0x10 ? string_nocheck+0x19c/0x310 ? number+0x739/0x9f0 ? __pfx_string_nocheck+0x10/0x10 ? __pfx_check_pointer+0x10/0x10 ? kvm_sched_clock_read+0x15/0x30 ? sched_clock_noinstr+0xd/0x20 ? local_clock_noinstr+0x1c/0xe0 __lock_acquire+0xc4b/0x62b0 ? __pfx_format_decode+0x10/0x10 ? __pfx_string+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ? __pfx_vsnprintf+0x10/0x10 lock_acquire+0x1e1/0x510 ? raw_spin_rq_lock_nested+0x2b/0x40 ? __pfx_lock_acquire+0x10/0x10 ? dump_line+0x12e/0x270 ? raw_spin_rq_lock_nested+0x20/0x40 _raw_spin_lock_nested+0x42/0x80 ? raw_spin_rq_lock_nested+0x2b/0x40 raw_spin_rq_lock_nested+0x2b/0x40 scx_dump_state+0x3b3/0x1270 ? finish_task_switch+0x27e/0x840 scx_ops_error_irq_workfn+0x67/0x80 irq_work_single+0x113/0x260 irq_work_run_list.part.3+0x44/0x70 run_irq_workd+0x6b/0x90 ? __pfx_run_irq_workd+0x10/0x10 smpboot_thread_fn+0x529/0x870 ? __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x305/0x3f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x40/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 This commit therefore use rq_lock_irqsave/irqrestore() to replacerq_lock/unlock() in the scx_dump_state().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68204 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: arm: scmi: Fix genpd leak on provider registration failureIf of_genpd_add_provider_onecell() fails during probe, the previouslycreated generic power domains are not removed, leading to a memory leakand potential kernel crash later in genpd_debug_add().Add proper error handling to unwind the initialized domains beforereturning from probe to ensure all resources are correctly released onfailure.Example crash trace observed without this fix: | Unable to handle kernel paging request at virtual address fffffffffffffc70 | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : genpd_debug_add+0x2c/0x160 | lr : genpd_debug_init+0x74/0x98 | Call trace: | genpd_debug_add+0x2c/0x160 (P) | genpd_debug_init+0x74/0x98 | do_one_initcall+0xd0/0x2d8 | do_initcall_level+0xa0/0x140 | do_initcalls+0x60/0xa8 | do_basic_setup+0x28/0x40 | kernel_init_freeable+0xe8/0x170 | kernel_init+0x2c/0x140 | ret_from_fork+0x10/0x20

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68206 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: add seqadj extension for natted connectionsSequence adjustment may be required for FTP traffic with PASV/EPSV modes.due to need to re-write packet payload (IP, port) on the ftp controlconnection. This can require changes to the TCP length and expectedseq / ack_seq.The easiest way to reproduce this issue is with PASV mode.Example ruleset:table inet ftp_nat { ct helper ftp_helper { type "ftp" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set "ftp_helper" }}table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { 192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { 192.168.13.2 : 192.168.100.1/32 } }}Note that the ftp helper gets assigned *after* the dnat setup.The inverse (nat after helper assign) is handled by an existingcheck in nf_nat_setup_info() and will not show the problem.Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ftp nat changes do not work as expected in this case:Connected to 192.168.100.1.[..]ftp> epsvEPSV/EPRT on IPv4 off.ftp> ls227 Entering passive mode (192,168,100,1,209,129).421 Service not available, remote server has closed connection.Kernel logs:Missing nfct_seqadj_ext_add() setup callWARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41[..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 ..Fix this by adding the required extension when a conntrack helper is assignedto a connection that has a nat binding.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68207 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/guc: Synchronize Dead CT worker with unbindCancel and wait for any Dead CT worker to complete before continuingwith device unbinding. Else the worker will end up using resources freedby the undind operation.(cherry picked from commit 492671339114e376aaa38626d637a2751cdef263)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68209 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlx5: Fix default values in create CQCurrently, CQs without a completion function are assigned themlx5_add_cq_to_tasklet function by default. This is problematic sinceonly user CQs created through the mlx5_ib driver are intended to usethis function.Additionally, all CQs that will use doorbells instead of polling forcompletions must call mlx5_cq_arm. However, the default CQ creation flowleaves a valid value in the CQ's arm_db field, allowing FW to sendinterrupts to polling-only CQs in certain corner cases.These two factors would allow a polling-only kernel CQ to be triggeredby an EQ interrupt and call a completion function intended only for userCQs, causing a null pointer exception.Some areas in the driver have prevented this issue with one-off fixesbut did not address the root cause.This patch fixes the described issue by adding defaults to the create CQflow. It adds a default dummy completion function to protect againstnull pointer exceptions, and it sets an invalid command sequence numberby default in kernel CQs to prevent the FW from sending an interrupt tothe CQ until it is armed. User CQs are responsible for their owninitialization values.Callers of mlx5_core_create_cq are responsible for changing thecompletion function and arming the CQ per their needs.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68210 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: avoid infinite loop due to incomplete zstd-compressed dataCurrently, the decompression logic incorrectly spins if compresseddata is truncated in crafted (deliberately corrupted) images.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68211 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ksm: use range-walk function to jump over holes in scan_get_next_rmap_itemCurrently, scan_get_next_rmap_item() walks every page address in a VMA tolocate mergeable pages. This becomes highly inefficient when scanninglarge virtual memory areas that contain mostly unmapped regions, causingksmd to use large amount of cpu without deduplicating much pages.This patch replaces the per-address lookup with a range walk usingwalk_page_range(). The range walker allows KSM to skip over entireunmapped holes in a VMA, avoiding unnecessary lookups. This problem waspreviously discussed in [1].Consider the following test program which creates a 32 TiB mapping in thevirtual address space but only populates a single page:#include #include #include /* 32 TiB */const size_t size = 32ul * 1024 * 1024 * 1024 * 1024;int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror("mmap() failed\n"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0;}$ ./ksm-sparse &$ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1hour in my test machine) scanning all the 32 TiB virtual address spacethat contain only one mapped page. This makes ksmd essentially deadlockednot able to deduplicate anything of value. With this patch ksmd walksonly the one mapped page and skips the rest of the 32 TiB virtual addressspace, making the scan fast using little cpu.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68213 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix possible vport_config NULL pointer deref in removeAttempting to remove the driver will cause a crash in cases wherethe vport failed to initialize. Following trace is from an instance wherethe driver failed during an attempt to create a VF:[ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated[ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms)[ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028...[ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf]...[ 1723.364973] Call Trace:[ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0[ 1723.366481] device_release_driver_internal+0x1a9/0x210[ 1723.366987] pci_stop_bus_device+0x6d/0x90[ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20[ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120[ 1723.368309] sriov_disable+0x34/0xe0[ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf][ 1723.368982] sriov_numvfs_store+0xda/0x1c0Avoid the NULL pointer dereference by adding NULL pointer check forvport_config[i], before freeing user_config.q_coalesce.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68214 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:timers: Fix NULL function pointer race in timer_shutdown_sync()There is a race condition between timer_shutdown_sync() and timerexpiration that can lead to hitting a WARN_ON in expire_timers().The issue occurs when timer_shutdown_sync() clears the timer functionto NULL while the timer is still running on another CPU. The racescenario looks like this:CPU0 CPU1 lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ...timer_shutdown_sync()lock_timer_base()// For now, will not detach the timer but only clear its function to NULLif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger expire_timers() WARN_ON_ONCE(!fn) // hit ...lock_timer_base()// Now timer will detachif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base()The problem is that timer_shutdown_sync() clears the timer functionregardless of whether the timer is currently running. This can leave apending timer with a NULL function pointer, which triggers theWARN_ON_ONCE(!fn) check in expire_timers().Fix this by only clearing the timer function when actually detaching thetimer. If the timer is running, leave the function pointer intact, which issafe because the timer will be properly detached when it finishes running.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68215 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix PTP cleanup on driver removal in error pathImprove the cleanup on releasing PTP resources in error path.The error case might happen either at the driver probe and PTPfeature initialization or on PTP restart (errors in reset handling, NVMupdate etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pffunction) and 'ps_lock' mutex deinitialization were missed.Additionally, ptp clock was not unregistered in the latter case.Keep PTP state as 'uninitialized' on init to distinguish between errorscenarios and to avoid resource release duplication at driver removal.The consequence of missing ice_ptp_cleanup_pf call is the following calltrace dumped when ice_adapter object is freed (port list is not empty,as it is required at this stage):[ T93022] ------------[ cut here ]------------[ T93022] WARNING: CPU: 10 PID: 93022 atice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice]...[ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice]...[ T93022] Call Trace:[ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice33d2647ad4f6d866d41eefff1806df37c68aef0c][ T93022] ? __warn.cold+0xb0/0x10e[ T93022] ? ice_adapter_put+0xef/0x100 [ice33d2647ad4f6d866d41eefff1806df37c68aef0c][ T93022] ? report_bug+0xd8/0x150[ T93022] ? handle_bug+0xe9/0x110[ T93022] ? exc_invalid_op+0x17/0x70[ T93022] ? asm_exc_invalid_op+0x1a/0x20[ T93022] ? ice_adapter_put+0xef/0x100 [ice33d2647ad4f6d866d41eefff1806df37c68aef0c][ T93022] pci_device_remove+0x42/0xb0[ T93022] device_release_driver_internal+0x19f/0x200[ T93022] driver_detach+0x48/0x90[ T93022] bus_remove_driver+0x70/0xf0[ T93022] pci_unregister_driver+0x42/0xb0[ T93022] ice_module_exit+0x10/0xdb0 [ice33d2647ad4f6d866d41eefff1806df37c68aef0c]...[ T93022] ---[ end trace 0000000000000000 ]---[ T93022] ice: module unloaded

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68217 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: pegasus-notetaker - fix potential out-of-bounds accessIn the pegasus_notetaker driver, the pegasus_probe() function allocatesthe URB transfer buffer using the wMaxPacketSize value fromthe endpoint descriptor. An attacker can use a malicious USB descriptorto force the allocation of a very small buffer.Subsequently, if the device sends an interrupt packet with a specificpattern (e.g., where the first byte is 0x80 or 0x42),the pegasus_parse_packet() function parses the packet without checkingthe allocated buffer size. This leads to an out-of-bounds memory access.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68218 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-multipath: fix lockdep WARN due to partition scan workBlktests test cases nvme/014, 057 and 058 fail occasionally due to alockdep WARN. As reported in the Closes tag URL, the WARN indicates thata deadlock can happen due to the dependency among disk->open_mutex,kblockd workqueue completion and partition_scan_work completion.To avoid the lockdep WARN and the potential deadlock, cut the dependencyby running the partition_scan_work not by kblockd workqueue but bynvme_wq.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68219 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix memory leak in smb3_fs_context_parse_param error pathAdd proper cleanup of ctx->source and fc->source to thecifs_parse_mount_err error handler. This ensures that memory allocatedfor the source strings is correctly freed on all error paths, matchingthe cleanup already performed in the success path bysmb3_cleanup_fs_context_contents().Pointers are also set to NULL after freeing to prevent potentialdouble-free issues.This change fixes a memory leak originally detected by syzbot. Theleak occurred when processing Opt_source mount options if an errorhappened after ctx->source and fc->source were successfullyallocated but before the function completed.The specific leak sequence was:1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory3. A subsequent error jumps to cifs_parse_mount_err4. The old error handler freed passwords but not the source strings,causing the memory to leak.This issue was not addressed by commit e8c73eb7db0a ("cifs: client:fix memory leak in smb3_fs_context_parse_param"), which only fixedleaks from repeated fsconfig() calls but not this error path.Patch updated with minor change suggested by kernel test robot

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68222 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_descs32_pinctrl_desc is allocated with devm_kmalloc(), but not all of itsfields are initialized. Notably, num_custom_params is used inpinconf_generic_parse_dt_config(), resulting in intermittent allocationerrors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...]This results in later parse failures that can cause issues in dependentdrivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registeredFix this by initializing s32_pinctrl_desc with devm_kzalloc() instead ofdevm_kmalloc() in s32_pinctrl_probe(), which sets the previouslyuninitialized fields to zero.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68227 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: Fix proto fallback detection with BPFThe sockmap feature allows bpf syscall from userspace, or basedon bpf sockops, replacing the sk_prot of sockets during protocol stackprocessing with sockmap's custom read/write interfaces.'''tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot'''When the server has MPTCP enabled but the client sends a TCP SYNwithout MPTCP, subflow_syn_recv_sock() performs a fallback on thesubflow, replacing the subflow sk's sk_prot with the native sk_prot.'''subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override()'''Then, this subflow can be normally used by sockmap, which replaces thenative sk_prot with sockmap's custom sk_prot. The issue occurs when theuser executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().Here, it uses sk->sk_prot to compare with the native sk_prot, but thisis incorrect when sockmap is used, as we may incorrectly setsk->sk_socket->ops.This fix uses the more generic sk_family for the comparison instead.Additionally, this also prevents a WARNING from occurring:result from ./scripts/decode_stacktrace.sh:------------[ cut here ]------------WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \(net/mptcp/protocol.c:4005)Modules linked in:...PKRU: 55555554Call Trace:do_accept (net/socket.c:1989)__sys_accept4 (net/socket.c:2028 net/socket.c:2057)__x64_sys_accept (net/socket.c:2067)x64_sys_call (arch/x86/entry/syscall_64.c:41)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)RIP: 0033:0x7f87ac92b83d---[ end trace 0000000000000000 ]---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68229 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and weattempt to dereference it in tcm_loop_tpg_address_show() we will get asegfault, see below for an example. So, check tl_hba->sh beforedereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0...

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68230 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix gpu page fault after hibernation on PF passthroughOn PF passthrough environment, after hibernate and then resume, coralgemmwill cause gpu page fault.Mode1 reset happens during hibernate, but partition mode is not restoredon resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not rightafter resume. When CP access the MQD BO, wrong stride size is used,this will cause out of bound access on the MQD BO, resulting page fault.The fix is to ensure gfx_v9_4_3_switch_compute_partition() is calledwhen resume from a hibernation.KFD resume is called separately during a reset recovery or resume fromsuspend sequence. Hence it's not required to be called as part ofpartition switch.(cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68231 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempool: fix poisoning order>0 pages with HIGHMEMThe kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283)Christoph found out this is due to the poisoning code not dealingproperly with CONFIG_HIGHMEM because only the first page is mapped butthen the whole potentially high-order page is accessed.We could give up on HIGHMEM here, but it's straightforward to fix thiswith a loop that's mapping, poisoning or checking and unmappingindividual pages.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68233 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: Add call to put_pid()Add a call to put_pid() corresponding to get_task_pid().host1x_memory_context_alloc() does not take ownership of the PID so weneed to free it here to avoid leaking.[mperttunen@nvidia.com: reword commit message]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68235 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::bootnvkm_falcon_fw::boot is allocated, but no one frees it. This causes akmemleak warning.Make sure this data is deallocated.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mtdchar: fix integer overflow in read/write ioctlsThe "req.start" and "req.len" variables are u64 values that come from theuser at the start of the function. We mask away the high 32 bits of"req.len" so that's capped at U32_MAX but the "req.start" variable can goup to U64_MAX which means that the addition can still integer overflow.Use check_add_overflow() to fix this bug.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68238 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: cadence: fix DMA device NULL pointer dereferenceThe DMA device pointer `dma_dev` was being dereferenced before ensuringthat `cdns_ctrl->dmac` is properly initialized.Move the assignment of `dma_dev` after successfully acquiring the DMAchannel to ensure the pointer is valid before use.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68239 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:binfmt_misc: restore write access before closing files opened by open_exec()bm_register_write() opens an executable file using open_exec(), whichinternally calls do_open_execat() and denies write access on the file toavoid modification while it is being executed.However, when an error occurs, bm_register_write() closes the file usingfilp_close() directly. This does not restore the write permission, whichmay cause subsequent write operations on the same file to fail.Fix this by calling exe_file_allow_write_access() before filp_close() torestore the write permission properly.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68241 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: route: Prevent rt_bind_exception() from rebinding stale fnheThe sit driver's packet transmission path calls: sit_tunnel_xmit() ->update_or_create_fnhe(), which lead to fnhe_remove_oldest() being calledto delete entries exceeding FNHE_RECLAIM_DEPTH+random.The race window is between fnhe_remove_oldest() selecting fnheX fordeletion and the subsequent kfree_rcu(). During this time, theconcurrent path's __mkroute_output() -> find_exception() can fetch thesoon-to-be-deleted fnheX, and rt_bind_exception() then binds it with anew dst using a dst_hold(). When the original fnheX is freed via RCU,the dst reference remains permanently leaked.CPU 0 CPU 1__mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak]This issue manifests as a device reference count leak and a warning indmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = NIdo Schimmel provided the simple test validation method [1].The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes().Since rt_bind_exception() checks this field, setting it to zero preventsthe stale fnhe from being reused and bound to a new dst just before itis freed.[1]ip netns add ns1ip -n ns1 link set dev lo upip -n ns1 address add 192.0.2.1/32 dev loip -n ns1 link add name dummy1 up type dummyip -n ns1 route add 192.0.2.2/32 dev dummy1ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2ip -n ns1 route add 198.51.0.0/16 dev gretap1taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &sleep 10ip netns pids ns1 | xargs killip netns del ns1

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68242 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix LTP test failures when timestamps are delegatedThe utimes01 and utime06 tests fail when delegated timestamps areenabled, specifically in subtests that modify the atime and mtimefields using the 'nobody' user ID.The problem can be reproduced as follow:# echo "/media *(rw,no_root_squash,sync)" >> /etc/exports# export -ra# mount -o rw,nfsvers=4.2 127.0.0.1:/media /tmpdir# cd /opt/ltp# ./runltp -d /tmpdir -s utimes01# ./runltp -d /tmpdir -s utime06This issue occurs because nfs_setattr does not verify the inode'sUID against the caller's fsuid when delegated timestamps arepermitted for the inode.This patch adds the UID check and if it does not match then therequest is sent to the server for permission checking.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68244 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTDOn completion of i915_vma_pin_ww(), a synchronous variant ofdma_fence_work_commit() is called. When pinning a VMA to GGTT addressspace on a Cherry View family processor, or on a Broxton generation SoCwith VTD enabled, i.e., when stop_machine() is then called fromintel_ggtt_bind_vma(), that can potentially lead to lock inversion amongreservation_ww and cpu_hotplug locks.[86.861179] ======================================================[86.861193] WARNING: possible circular locking dependency detected[86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U[86.861226] ------------------------------------------------------[86.861238] i915_module_loa/1432 is trying to acquire lock:[86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50[86.861290]but task is already holding lock:[86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915][86.862233]which lock already depends on the new lock.[86.862251]the existing dependency chain (in reverse order) is:[86.862265]-> #5 (reservation_ww_class_mutex){+.+.}-{3:3}:[86.862292] dma_resv_lockdep+0x19a/0x390[86.862315] do_one_initcall+0x60/0x3f0[86.862334] kernel_init_freeable+0x3cd/0x680[86.862353] kernel_init+0x1b/0x200[86.862369] ret_from_fork+0x47/0x70[86.862383] ret_from_fork_asm+0x1a/0x30[86.862399]-> #4 (reservation_ww_class_acquire){+.+.}-{0:0}:[86.862425] dma_resv_lockdep+0x178/0x390[86.862440] do_one_initcall+0x60/0x3f0[86.862454] kernel_init_freeable+0x3cd/0x680[86.862470] kernel_init+0x1b/0x200[86.862482] ret_from_fork+0x47/0x70[86.862495] ret_from_fork_asm+0x1a/0x30[86.862509]-> #3 (&mm->mmap_lock){++++}-{3:3}:[86.862531] down_read_killable+0x46/0x1e0[86.862546] lock_mm_and_find_vma+0xa2/0x280[86.862561] do_user_addr_fault+0x266/0x8e0[86.862578] exc_page_fault+0x8a/0x2f0[86.862593] asm_exc_page_fault+0x27/0x30[86.862607] filldir64+0xeb/0x180[86.862620] kernfs_fop_readdir+0x118/0x480[86.862635] iterate_dir+0xcf/0x2b0[86.862648] __x64_sys_getdents64+0x84/0x140[86.862661] x64_sys_call+0x1058/0x2660[86.862675] do_syscall_64+0x91/0xe90[86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e[86.862703]-> #2 (&root->kernfs_rwsem){++++}-{3:3}:[86.862725] down_write+0x3e/0xf0[86.862738] kernfs_add_one+0x30/0x3c0[86.862751] kernfs_create_dir_ns+0x53/0xb0[86.862765] internal_create_group+0x134/0x4c0[86.862779] sysfs_create_group+0x13/0x20[86.862792] topology_add_dev+0x1d/0x30[86.862806] cpuhp_invoke_callback+0x4b5/0x850[86.862822] cpuhp_issue_call+0xbf/0x1f0[86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320[86.862852] __cpuhp_setup_state+0xb0/0x220[86.862866] topology_sysfs_init+0x30/0x50[86.862879] do_one_initcall+0x60/0x3f0[86.862893] kernel_init_freeable+0x3cd/0x680[86.862908] kernel_init+0x1b/0x200[86.862921] ret_from_fork+0x47/0x70[86.862934] ret_from_fork_asm+0x1a/0x30[86.862947]-> #1 (cpuhp_state_mutex){+.+.}-{3:3}:[86.862969] __mutex_lock+0xaa/0xed0[86.862982] mutex_lock_nested+0x1b/0x30[86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320[86.863012] __cpuhp_setup_state+0xb0/0x220[86.863026] page_alloc_init_cpuhp+0x2d/0x60[86.863041] mm_core_init+0x22/0x2d0[86.863054] start_kernel+0x576/0xbd0[86.863068] x86_64_start_reservations+0x18/0x30[86.863084] x86_64_start_kernel+0xbf/0x110[86.863098] common_startup_64+0x13e/0x141[86.863114]-> #0 (cpu_hotplug_lock){++++}-{0:0}:[86.863135] __lock_acquire+0x16---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68245 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: netpoll: fix incorrect refcount handling causing incorrect cleanupcommit efa95b01da18 ("netpoll: fix use after free") incorrectlyignored the refcount and prematurely set dev->npinfo to NULL duringnetpoll cleanup, leading to improper behavior and memory leaks.Scenario causing lack of proper cleanup:1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one.2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev.3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak.Revert commit efa95b01da18 ("netpoll: fix use after free") and addsclarifying comments emphasizing that npinfo cleanup should only happenonce the refcount reaches zero, ensuring stable and correct netpollbehavior.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68249 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: hdm_probe: Fix calling put_device() before device initializationThe early error path in hdm_probe() can jump to err_free_mdev before&mdev->dev has been initialized with device_initialize(). Callingput_device(&mdev->dev) there triggers a device core WARN and ends upinvoking kref_put(&kobj->kref, kobject_release) on an uninitializedkobject.In this path the private struct was only kmalloc'ed and the intendedrelease is effectively kfree(mdev) anyway, so free it directly insteadof calling put_device() on an uninitialized device.This removes the WARNING and fixes the pre-initialization error path.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68251 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: avoid infinite loops due to corrupted subpage compact indexesRobert reported an infinite loop observed by two crafted images.The root cause is that `clusterofs` can be larger than `lclustersize`for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.: blocksize = lclustersize = 512 lcn = 6 clusterofs = 515Move the corresponding check for full compress indexes to`z_erofs_load_lcluster_from_disk()` to also cover subpage compactcompress indexes.It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX`check, since it should be placed right after`z_erofs_load_{compact,full}_lcluster()`.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68252 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookupIn fastrpc_map_lookup, dma_buf_get is called to obtain a reference tothe dma_buf for comparison purposes. However, this reference is neverreleased when the function returns, leading to a dma_buf memory leak.Fix this by adding dma_buf_put before returning from the function,ensuring that the temporarily acquired reference is properly releasedregardless of whether a matching map is found.Rule: add

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68254 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsingThe Extended Supported Rates (ESR) IE handling in OnBeacon accessed*(p + 1 + ielen) and *(p + 2 + ielen) without verifying that theseoffsets lie within the received frame buffer. A malformed beacon withan ESR IE positioned at the end of the buffer could cause anout-of-bounds read, potentially triggering a kernel panic.Add a boundary check to ensure that the ESR IE body and the subsequentbytes are within the limits of the frame before attempting to accessthem.This prevents OOB reads caused by malformed beacon frames.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68256 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parserThe Information Element (IE) parser rtw_get_ie() trusted the lengthbyte of each IE without validating that the IE body (len bytes afterthe 2-byte header) fits inside the remaining frame buffer. A malformedframe can advertise an IE length larger than the available data, causingthe parser to increment its pointer beyond the buffer end. This resultsin out-of-bounds reads or, depending on the pattern, an infinite loop.Fix by validating that (offset + 2 + len) does not exceed the limitbefore accepting the IE or advancing to the next element.This prevents OOB reads and ensures the parser terminates safely onmalformed frames.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68257 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: check device's attached status in compat ioctlsSyzbot identified an issue [1] that crashes kernel, seemingly due tounexistent callback dev->get_valid_routes(). By all means, this shouldnot occur as said callback must always be set toget_zero_valid_routes() in __comedi_device_postconfig().As the crash seems to appear exclusively in i386 kernels, at least,judging from [1] reports, the blame lies with compat versionsof standard IOCTL handlers. Several of them are modified anddo not use comedi_unlocked_ioctl(). While functionality of theseioctls essentially copy their original versions, they do nothave required sanity check for device's attached status. This,in turn, leads to a possibility of calling select IOCTLs on adevice that has not been properly setup, even via COMEDI_DEVCONFIG.Doing so on unconfigured devices means that several crucial stepsare missed, for instance, specifying dev->get_valid_routes()callback.Fix this somewhat crudely by ensuring device's attached status beforeperforming any ioctls, improving logic consistency between modernand compat functions.[1] Syzbot report:BUG: kernel NULL pointer dereference, address: 0000000000000000...CR2: ffffffffffffffd6 CR3: 000000006c717000 CR4: 0000000000352ef0Call Trace: get_valid_routes drivers/comedi/comedi_fops.c:1322 [inline] parse_insn+0x78c/0x1970 drivers/comedi/comedi_fops.c:1401 do_insnlist_ioctl+0x272/0x700 drivers/comedi/comedi_fops.c:1594 compat_insnlist drivers/comedi/comedi_fops.c:3208 [inline] comedi_compat_ioctl+0x810/0x990 drivers/comedi/comedi_fops.c:3273 __do_compat_sys_ioctl fs/ioctl.c:695 [inline] __se_compat_sys_ioctl fs/ioctl.c:638 [inline] __ia32_compat_sys_ioctl+0x242/0x370 fs/ioctl.c:638 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]...

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68258 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: multiq3: sanitize config options in multiq3_attach()Syzbot identified an issue [1] in multiq3_attach() that induces atask timeout due to open() or COMEDI_DEVCONFIG ioctl operations,specifically, in the case of multiq3 driver.This problem arose when syzkaller managed to craft weird configurationoptions used to specify the number of channels in encoder subdevice.If a particularly great number is passed to s->n_chan inmultiq3_attach() via it->options[2], then multiple calls tomultiq3_encoder_reset() at the end of driver-specific attach() methodwill be running for minutes, thus blocking tasks and affected devicesas well.While this issue is most likely not too dangerous for real-lifedevices, it still makes sense to sanitize configuration inputs. Enablea sensible limit on the number of encoder chips (4 chips max, eachwith 2 channels) to stop this behaviour from manifesting.[1] Syzbot crash:INFO: task syz.2.19:6067 blocked for more than 143 seconds....Call Trace: context_switch kernel/sched/core.c:5254 [inline] __schedule+0x17c4/0x4d60 kernel/sched/core.c:6862 __schedule_loop kernel/sched/core.c:6944 [inline] schedule+0x165/0x360 kernel/sched/core.c:6959 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016 __mutex_lock_common kernel/locking/mutex.c:676 [inline] __mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760 comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868 chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414 do_dentry_open+0x953/0x13f0 fs/open.c:965 vfs_open+0x3b/0x340 fs/open.c:1097...

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68259 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replacedWhen re-injecting a soft interrupt from an INT3, INT0, or (select) INTninstruction, discard the exception and retry the instruction if the codestream is changed (e.g. by a different vCPU) between when the CPUexecutes the instruction and when KVM decodes the instruction to get thenext RIP.As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-injectINT3/INTO instead of retrying the instruction"), failure to verify thatthe correct INTn instruction was decoded can effectively clobber gueststate due to decoding the wrong instruction and thus specifying thewrong next RIP.The bug most often manifests as "Oops: int3" panics on static branchchecks in Linux guests. Enabling or disabling a static branch in Linuxuses the kernel's "text poke" code patching mechanism. To modify codewhile other CPUs may be executing that code, Linux (temporarily)replaces the first byte of the original instruction with an int3 (opcode0xcc), then patches in the new code stream except for the first byte,and finally replaces the int3 with the first byte of the new codestream. If a CPU hits the int3, i.e. executes the code while it's beingmodified, then the guest kernel must look up the RIP to determine how tohandle the #BP, e.g. by emulating the new instruction. If the RIP isincorrect, then this lookup fails and the guest kernel panics.The bug reproduces almost instantly by hacking the guest kernel torepeatedly check a static branch[1] while running a drgn script[2] onthe host to constantly swap out the memory containing the guest's TSS.[1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a[2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68261 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()Fix a race between inline data destruction and block mapping.The function ext4_destroy_inline_data_nolock() changes the inode datalayout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.At the same time, another thread may execute ext4_map_blocks(), whichtests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()or ext4_ind_map_blocks().Without i_data_sem protection, ext4_ind_map_blocks() may receive inodewith EXT4_INODE_EXTENTS flag and triggering assert.kernel BUG at fs/ext4/indirect.c:546!EXT4-fs (loop2): unmounting filesystem.invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTIHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546Call Trace: ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681 _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000 generic_perform_write+0x259/0x5d0 mm/filemap.c:3846 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679 call_write_iter include/linux/fs.h:2271 [inline] do_iter_readv_writev+0x212/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+0x10f/0x170 fs/splice.c:950 splice_direct_to_actor+0x33a/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

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68276 Severity: Moderate CVSS3 score: 5.5

Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, an unprivileged local users can crash avahi-daemon (with wide-area disabled) by creating record browsers with the AVAHI_LOOKUP_USE_WIDE_AREA flag set via D-Bus. This can be done by either callingthe RecordBrowserNew method directly or creating hostname/address/service resolvers/browsers that create those browsers internally themselves.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libavahi-client3 < 0.8-160000.4.1 (version in image is 0.8-160000.2.2).

CVE-2025-68282 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: udc: fix use-after-free in usb_gadget_state_workA race condition during gadget teardown can lead to a use-after-freein usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_workThe fundamental race occurs because a concurrent event (e.g., aninterrupt) can call usb_gadget_set_state() and schedule gadget->workat any time during the cleanup process in usb_del_gadget().Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue afterdevice removal") attempted to fix this by moving flush_work() to afterdevice_del(). However, this does not fully solve the race, as a newwork item can still be scheduled *after* flush_work() completes butbefore the gadget's memory is freed, leading to the same use-after-free.This patch fixes the race condition robustly by introducing a 'teardown'flag and a 'state_lock' spinlock to the usb_gadget struct. The flag isset during cleanup in usb_del_gadget() *before* calling flush_work() toprevent any new work from being scheduled once cleanup has commenced.The scheduling site, usb_gadget_set_state(), now checks this flag underthe lock before queueing the work, thus safely closing the race window.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68287 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call pathsThis patch addresses a race condition caused by unsynchronizedexecution of multiple call paths invoking `dwc3_remove_requests()`,leading to premature freeing of USB requests and subsequent crashes.Three distinct execution paths interact with `dwc3_remove_requests()`:Path 1:Triggered via `dwc3_gadget_reset_interrupt()` during USB resethandling. The call stack includes:- `dwc3_ep0_reset_state()`- `dwc3_ep0_stall_and_restart()`- `dwc3_ep0_out_start()`- `dwc3_remove_requests()`- `dwc3_gadget_del_and_unmap_request()`Path 2:Also initiated from `dwc3_gadget_reset_interrupt()`, but through`dwc3_stop_active_transfers()`. The call stack includes:- `dwc3_stop_active_transfers()`- `dwc3_remove_requests()`- `dwc3_gadget_del_and_unmap_request()`Path 3:Occurs independently during `adb root` execution, which triggersUSB function unbind and bind operations. The sequence includes:- `gserial_disconnect()`- `usb_ep_disable()`- `dwc3_gadget_ep_disable()`- `dwc3_remove_requests()` with `-ESHUTDOWN` statusPath 3 operates asynchronously and lacks synchronization with Paths1 and 2. When Path 3 completes, it disables endpoints and frees 'out'requests. If Paths 1 or 2 are still processing these requests,accessing freed memory leads to a crash due to use-after-free conditions.To fix this added check for request completion and skip processingif already completed and added the request status for ep0 while queue.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68289 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_eem: Fix memory leak in eem_unwrapThe existing code did not handle the failure case of usb_ep_queue in thecommand path, potentially leading to memory leaks.Improve error handling to free all allocated resources on usb_ep_queuefailure. This patch continues to use goto logic for error handling, as theexisting error handling is complex and not easily adaptable to auto-cleanuphelpers.kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68290 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: fix double free on late probe failureThe MOST subsystem has a non-standard registration function which freesthe interface on registration failures and on deregistration.This unsurprisingly leads to bugs in the MOST drivers, and a couple ofrecent changes turned a reference underflow and use-after-free in theUSB driver into several double free and a use-after-free on late probefailures.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68292 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/memfd: fix information leak in hugetlb foliosWhen allocating hugetlb folios for memfd, three initialization steps aremissing:1. Folios are not zeroed, leading to kernel memory disclosure to userspace2. Folios are not marked uptodate before adding to page cache3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache()The memfd allocation path bypasses the normal page fault handler(hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios arepinned and directly accessed by userspace via DMA.Fix by matching the initialization pattern used in hugetlb_no_page():- Zero the folio using folio_zero_user() which is optimized for huge pages- Mark it uptodate with folio_mark_uptodate()- Take hugetlb_fault_mutex before adding to page cache to prevent racesThe folio_zero_user() change also fixes a potential security issue whereuninitialized kernel memory could be disclosed to userspace through read()or mmap() operations on the memfd.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68293 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/huge_memory: fix NULL pointer deference when splitting folioCommit c010d47f107f ("mm: thp: split huge page to any lower order pages")introduced an early check on the folio's order via mapping->flags beforeproceeding with the split work.This check introduced a bug: for shmem folios in the swap cache andtruncated folios, the mapping pointer can be NULL. Accessingmapping->flags in this state leads directly to a NULL pointer dereference.This commit fixes the issue by moving the check for mapping != NULL beforeany attempt to access mapping->flags.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68295 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix memory leak in cifs_construct_tcon()When having a multiuser mount with domain= specified and usingcifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname,so it needs to be freed before leaving cifs_construct_tcon().This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68296 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setupProtect vga_switcheroo_client_fb_set() with console lock. Avoids OOBaccess in fbcon_remap_all(). Without holding the console lock the callraces with switching outputs.VGA switcheroo calls fbcon_remap_all() when switching clients. The fbconfunction uses struct fb_info.node, which is set by register_framebuffer().As the fb-helper code currently sets up VGA switcheroo before registeringthe framebuffer, the value of node is -1 and therefore not a legal value.For example, fbcon uses the value within set_con2fb_map() [1] as an indexinto an array.Moving vga_switcheroo_client_fb_set() after register_framebuffer() canresult in VGA switching that does not switch fbcon correctly.Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),which already holds the console lock. Fbdev calls fbcon_fb_registered()from within register_framebuffer(). Serializes the helper with VGAswitcheroo's call to fbcon_remap_all().Although vga_switcheroo_client_fb_set() takes an instance of struct fb_infoas parameter, it really only needs the contained fbcon state. Moving thecall to fbcon initialization is therefore cleaner than before. Only amdgpu,i915, nouveau and radeon support vga_switcheroo. For all other drivers,this change does nothing.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68297 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix crash in process_v2_sparse_read() for encrypted directoriesThe crash in process_v2_sparse_read() for fscrypt-encrypted directorieshas been reported. Issue takes place for Ceph msgr2 protocol in securemode. It can be reproduced by the steps:sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure(1) mkdir /mnt/cephfs/fscrypt-test-3(2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3(3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3(4) fscrypt lock /mnt/cephfs/fscrypt-test-3(5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3(6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar(7) Issue has been triggered[ 408.072247] ------------[ cut here ]------------[ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865ceph_con_v2_try_read+0x4b39/0x72f0[ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_commonintel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discoverypmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypasspolyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouseserio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfgpata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore[ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+[ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.17.0-5.fc42 04/01/2014[ 408.072310] Workqueue: ceph-msgr ceph_con_workfn[ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0[ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f88e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85[ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246[ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38[ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8[ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8[ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000[ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000)knlGS:0000000000000000[ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0[ 408.072336] PKRU: 55555554[ 408.072337] Call Trace:[ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10[ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10[ 408.072347] ? _raw_spin_unlock+0xe/0x40[ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830[ 408.072353] ? __kasan_check_write+0x14/0x30[ 408.072357] ? mutex_lock+0x84/0xe0[ 408.072359] ? __pfx_mutex_lock+0x10/0x10[ 408.072361] ceph_con_workfn+0x27e/0x10e0[ 408.072364] ? metric_delayed_work+0x311/0x2c50[ 408.072367] process_one_work+0x611/0xe20[ 408.072371] ? __kasan_check_write+0x14/0x30[ 408.072373] worker_thread+0x7e3/0x1580[ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10[ 408.072378] ? __pfx_worker_thread+0x10/0x10[ 408.072381] kthread+0x381/0x7a0[ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10[ 408.072385] ? __pfx_kthread+0x10/0x10[ 408.072387] ? __kasan_check_write+0x14/0x30[ 408.072389] ? recalc_sigpending+0x160/0x220[ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50[ 408.072394] ? calculate_sigpending+0x78/0xb0[ 408.072395] ? __pfx_kthread+0x10/0x10[ 408.072397] ret_from_fork+0x2b6/0x380[ 408.072400] ? __pfx_kthread+0x10/0x10[ 408.072402] ret_from_fork_asm+0x1a/0x30[ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]---[ 408.072418] Oops: general protection fault, probably for non-canonicaladdress 0xdffffc00000000---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68298 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL derefIn btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM)That function can return NULL in some cases. Even when it returnsNULL, though, we still go on to call btusb_mtk_claim_iso_intf().As of commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks forusb_driver_claim_interface()"), calling btusb_mtk_claim_iso_intf()when `btmtk_data->isopkt_intf` is NULL will cause a crash becausewe'll end up passing a bad pointer to device_lock(). Prior to thatcommit we'd pass the NULL pointer directly tousb_driver_claim_interface() which would detect it and return anerror, which was handled.Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL checkat the start of the function. This makes the code handle a NULL`btmtk_data->isopkt_intf` the same way it did before the problematiccommit (just with a slight change to the error message printed).

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68301 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: atlantic: fix fragment overflow handling in RX pathThe atlantic driver can receive packets with more than MAX_SKB_FRAGS (17)fragments when handling large multi-descriptor packets. This causes anout-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic.The issue occurs because the driver doesn't check the total number offragments before calling skb_add_rx_frag(). When a packet requires morethan MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds.Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE,then all fragments are accounted for. And reusing the existing check toprevent the overflow earlier in the code path.This crash occurred in production with an Aquantia AQC113 10G NIC.Stack trace from production environment:```RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 4889 fa 83RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:fffffffe0a0c8000RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:0000000000037a40RBP: 0000000000000024 R08: 0000000000000000 R09:0000000000000021R10: 0000000000000848 R11: 0000000000000000 R12:ffffa9bec02a8e24R13: ffff925ad8615570 R14: 0000000000000000 R15:ffff925b22e80a00FS: 0000000000000000(0000)GS:ffff925e47880000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:0000000000f72ef0PKRU: 55555554Call Trace:aq_ring_rx_clean+0x175/0xe60 [atlantic]? aq_ring_rx_clean+0x14d/0xe60 [atlantic]? aq_ring_tx_clean+0xdf/0x190 [atlantic]? kmem_cache_free+0x348/0x450? aq_vec_poll+0x81/0x1d0 [atlantic]? __napi_poll+0x28/0x1c0? net_rx_action+0x337/0x420```Changes in v4:- Add Fixes: tag to satisfy patch validation requirements.Changes in v3:- Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68302 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sxgbe: fix potential NULL dereference in sxgbe_rx()Currently, when skb is null, the driver prints an error and thendereferences skb on the next line.To fix this, let's add a 'break' after the error message to switchto sxgbe_rx_refill(), which is similar to the approach taken by theother drivers in this particular case, e.g. calxeda with xgmac_rx().Found during a code review.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68303 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: intel: punit_ipc: fix memory corruptionThis passes the address of the pointer "&punit_ipcdev" when the intentwas to pass the pointer itself "punit_ipcdev" (without the ampersand).This means that the: complete(&ipcdev->cmd_complete);in intel_punit_ioc() will write to a wrong memory address corrupting it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68304 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: lookup hci_conn on RX path on protocol sideThe hdev lock/lookup/unlock/use pattern in the packet RX path doesn'tensure hci_conn* is not concurrently modified/deleted. This lockingappears to be leftover from before conn_hash started using RCUcommit bf4c63252490b ("Bluetooth: convert conn hash to RCU")and not clear if it had purpose since then.Currently, there are code paths that delete hci_conn* from elsewherethan the ordered hdev->workqueue where the RX work runs in. E.g.commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync")introduced some of these, and there probably were a few others beforeit. It's better to do the locking so that even if these runconcurrently no UAF is possible.Move the lookup of hci_conn and associated socket-specific conn toprotocol recv handlers, and do them within a single critical sectionto cover hci_conn* usage and lookup.syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68305 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sock: Prevent race in socket write iter and sock bindThere is a potential race condition between sock bind and socket writeiter. bind may free the same cmd via mgmt_pending before write iter sendsthe cmd, just as syzbot reported in UAF[1].Here we use hci_dev_lock to synchronize the two, thereby avoiding theUAF mentioned in [1].[1]syzbot reported:BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316Read of size 8 at addr ffff888077164818 by task syz.0.17/5989Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 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:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 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:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68306 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interfaceWhen performing reset tests and encountering abnormal card drop issuesthat lead to a kernel crash, it is necessary to perform a null checkbefore releasing resources to avoid attempting to release a null pointer.<4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT)<4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth]<4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<4>[ 29.158162] pc : klist_remove+0x90/0x158<4>[ 29.158174] lr : klist_remove+0x88/0x158<4>[ 29.158180] sp : ffffffc0846b3c00<4>[ 29.158185] pmr_save: 000000e0<4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058<4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0<4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290<4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781<4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428<4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018<4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000<4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d<4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e<4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c<4>[ 29.158285] Call trace:<4>[ 29.158290] klist_remove+0x90/0x158<4>[ 29.158298] device_release_driver_internal+0x20c/0x268<4>[ 29.158308] device_release_driver+0x1c/0x30<4>[ 29.158316] usb_driver_release_interface+0x70/0x88<4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)]<4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)]<4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)]<4>[ 29.158430] process_scheduled_works+0x258/0x4e8<4>[ 29.158441] worker_thread+0x300/0x428<4>[ 29.158448] kthread+0x108/0x1d0<4>[ 29.158455] ret_from_fork+0x10/0x20<0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297)<4>[ 29.158474] ---[ end trace 0000000000000000 ]---<0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception<2>[ 29.167144] SMP: stopping secondary CPUs<4>[ 29.167158] ------------[ cut here ]------------

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68308 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: kvaser_usb: leaf: Fix potential infinite loop in command parsersThe `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback`functions contain logic to zero-length commands. These commands are usedto align data to the USB endpoint's wMaxPacketSize boundary.The driver attempts to skip these placeholders by aligning the bufferposition `pos` to the next packet boundary using `round_up()` function.However, if zero-length command is found exactly on a packet boundary(i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up`function will return the unchanged value of `pos`. This prevents `pos`to be increased, causing an infinite loop in the parsing logic.This patch fixes this in the function by using `pos + 1` instead.This ensures that even if `pos` is on a boundary, the calculation isbased on `pos + 1`, forcing `round_up()` to always return the nextaligned boundary.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68311 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: ip22zilog: Use platform device for probingAfter commit 84a9582fd203 ("serial: core: Start managing serial controllersto enable runtime PM") serial drivers need to provide a device instruct uart_port.dev otherwise an oops happens. To fix this issuefor ip22zilog driver switch driver to a platform driver and setupthe serial device in sgi-ip22 code.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68312 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: Prevents free active keventThe root cause of this issue are:1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0);put the kevent work in global workqueue. However, the kevent has not yetbeen scheduled when the usbnet device is unregistered. Therefore, executingfree_netdev() results in the "free active object (kevent)" error reportedhere.2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(),if the usbnet device is up, ndo_stop() is executed to cancel the kevent.However, because the device is not up, ndo_stop() is not executed.The solution to this problem is to cancel the kevent before executingfree_netdev().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68319 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netconsole: Acquire su_mutex before navigating configs hierarchyThere is a race between operations that iterate over the userdatacg_children list and concurrent add/remove of userdata items throughconfigfs. The update_userdata() function iterates over thent->userdata_group.cg_children list, and count_extradata_entries() alsoiterates over this same list to count nodes.Quoting from Documentation/filesystems/configfs.rst:> A subsystem can navigate the cg_children list and the ci_parent pointer> to see the tree created by the subsystem. This can race with configfs'> management of the hierarchy, so configfs uses the subsystem mutex to> protect modifications. Whenever a subsystem wants to navigate the> hierarchy, it must do so under the protection of the subsystem> mutex.Without proper locking, if a userdata item is added or removedconcurrently while these functions are iterating, the list can beaccessed in an inconsistent state. For example, the list_for_each() loopcan reach a node that is being removed from the list by list_del_init()which sets the nodes' .next pointer to point to itself, so the loop willnever end (or reach the WARN_ON_ONCE in update_userdata() ).Fix this by holding the configfs subsystem mutex (su_mutex) during alloperations that iterate over cg_children.This includes:- userdatum_value_store() which calls update_userdata() to iterate over cg_children- All sysdata_*_enabled_store() functions which call count_extradata_entries() to iterate over cg_childrenThe su_mutex must be acquired before dynamic_netconsole_mutex to avoidpotential lock ordering issues, as configfs operations may already holdsu_mutex when calling into our code.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68320 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:lan966x: Fix sleeping in atomic contextThe following warning was seen when we try to connect using ssh to the device.BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbearpreempt_count: 1, expected: 0INFO: lockdep is turned off.CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G W 6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONETainted: [W]=WARNHardware name: Generic DT based systemCall trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x7c/0xac dump_stack_lvl from __might_resched+0x16c/0x2b0 __might_resched from __mutex_lock+0x64/0xd34 __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from lan966x_stats_get+0x5c/0x558 lan966x_stats_get from dev_get_stats+0x40/0x43c dev_get_stats from dev_seq_printf_stats+0x3c/0x184 dev_seq_printf_stats from dev_seq_show+0x10/0x30 dev_seq_show from seq_read_iter+0x350/0x4ec seq_read_iter from seq_read+0xfc/0x194 seq_read from proc_reg_read+0xac/0x100 proc_reg_read from vfs_read+0xb0/0x2b0 vfs_read from ksys_read+0x6c/0xec ksys_read from ret_fast_syscall+0x0/0x1cException stack(0xf0b11fa8 to 0xf0b11ff0)1fa0: 00000001 00001000 00000008 be9048d8 00001000 000000011fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 000000011fe0: 0005404c be9048c0 00018684 b6ec2cd8It seems that we are using a mutex in a atomic context which is wrong.Change the mutex with a spinlock.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68325 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_cake: Fix incorrect qlen reduction in cake_dropIn cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlenand backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumesthat the parent qdisc will enqueue the current packet. However, thisassumption breaks when cake_enqueue() returns NET_XMIT_CN: the parentqdisc stops enqueuing current packet, leaving the tree qlen/backlogaccounting inconsistent. This mismatch can lead to a NULL dereference(e.g., when the parent Qdisc is qfq_qdisc).This patch computes the qlen/backlog delta in a more robust way byobserving the difference before and after the series of cake_drop()calls, and then compensates the qdisc tree accounting if cake_enqueue()returns NET_XMIT_CN.To ensure correct compensation when ACK thinning is enabled, a newvariable is introduced to keep qlen unchanged.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68329 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAsWhen a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernelcalls vm_ops->close on each portion. For trace buffer mappings, thisresults in ring_buffer_unmap() being called multiple times whilering_buffer_map() was only called once.This causes ring_buffer_unmap() to return -ENODEV on subsequent callsbecause user_mapped is already 0, triggering a WARN_ON.Trace buffer mappings cannot support partial mappings because the ringbuffer structure requires the complete buffer including the meta page.Fix this by adding a may_split callback that returns -EINVAL to preventVMA splits entirely.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68330 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: accel: bmc150: Fix irq assumption regressionThe code in bmc150-accel-core.c unconditionally callsbmc150_accel_set_interrupt() in the iio_buffer_setup_ops,such as on the runtime PM resume path giving a kernelsplat like this if the device has no interrupts:Unable to handle kernel NULL pointer dereference at virtual address 00000001 when readPC is at bmc150_accel_set_interrupt+0x98/0x194LR is at __pm_runtime_resume+0x5c/0x64(...)Call trace:bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc__iio_update_buffers from enable_store+0x84/0xc8enable_store from kernfs_fop_write_iter+0x154/0x1b4This bug seems to have been in the driver since the beginning,but it only manifests recently, I do not know why.Store the IRQ number in the state struct, as this is a commonpattern in other drivers, then use this to determine if we haveIRQ support or not.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68332 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: c6xdigio: Fix invalid PNP driver unregistrationThe Comedi low-level driver "c6xdigio" seems to be for a parallel portconnected device. When the Comedi core calls the driver's Comedi"attach" handler `c6xdigio_attach()` to configure a Comedi to use thisdriver, it tries to enable the parallel port PNP resources byregistering a PNP driver with `pnp_register_driver()`, but ignores thereturn value. (The `struct pnp_driver` it uses has only the `name` and`id_table` members filled in.) The driver's Comedi "detach" handler`c6xdigio_detach()` unconditionally unregisters the PNP driver with`pnp_unregister_driver()`.It is possible for `c6xdigio_attach()` to return an error before itcalls `pnp_register_driver()` and it is possible for the call to`pnp_register_driver()` to return an error (that is ignored). In bothcases, the driver should not be calling `pnp_unregister_driver()` as itdoes in `c6xdigio_detach()`. (Note that `c6xdigio_detach()` will becalled by the Comedi core if `c6xdigio_attach()` returns an error, or ifthe Comedi core decides to detach the Comedi device from the driver forsome other reason.)The unconditional call to `pnp_unregister_driver()` without a previoussuccessful call to `pnp_register_driver()` will cause`driver_unregister()` to issue a warning "Unexpected driverunregister!". This was detected by Syzbot [1].Also, the PNP driver registration and unregistration should be done atmodule init and exit time, respectively, not when attaching or detachingComedi devices to the driver. (There might be more than one Comedidevice being attached to the driver, although that is unlikely.)Change the driver to do the PNP driver registration at module init time,and the unregistration at module exit time. Since `c6xdigio_detach()`now only calls `comedi_legacy_detach()`, remove the function and changethe Comedi driver "detach" handler to `comedi_legacy_detach`.-------------------------------------------[1] Syzbot sample crash report:Unexpected driver unregister!WARNING: CPU: 0 PID: 5970 at drivers/base/driver.c:273 driver_unregister drivers/base/driver.c:273 [inline]WARNING: CPU: 0 PID: 5970 at drivers/base/driver.c:273 driver_unregister+0x90/0xb0 drivers/base/driver.c:270Modules linked in:CPU: 0 UID: 0 PID: 5970 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025RIP: 0010:driver_unregister drivers/base/driver.c:273 [inline]RIP: 0010:driver_unregister+0x90/0xb0 drivers/base/driver.c:270Code: 48 89 ef e8 c2 e6 82 fc 48 89 df e8 3a 93 ff ff 5b 5d e9 c3 6d d9 fb e8 be 6d d9 fb 90 48 c7 c7 e0 f8 1f 8c e8 51 a2 97 fb 90 <0f> 0b 90 90 5b 5d e9 a5 6d d9 fb e8 e0 f4 41 fc eb 94 e8 d9 f4 41RSP: 0018:ffffc9000373f9a0 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffffffff8ff24720 RCX: ffffffff817b6ee8RDX: ffff88807c932480 RSI: ffffffff817b6ef5 RDI: 0000000000000001RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000001 R12: ffffffff8ff24660R13: dffffc0000000000 R14: 0000000000000000 R15: ffff88814cca0000FS: 000055556dab1500(0000) GS:ffff8881249d9000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055f77f285cd0 CR3: 000000007d871000 CR4: 00000000003526f0Call Trace: comedi_device_detach_locked+0x12f/0xa50 drivers/comedi/drivers.c:207 comedi_device_detach+0x67/0xb0 drivers/comedi/drivers.c:215 comedi_device_attach+0x43d/0x900 drivers/comedi/drivers.c:1011 do_devconfig_ioctl+0x1b1/0x710 drivers/comedi/comedi_fops.c:872 comedi_unlocked_ioctl+0x165d/0x2f00 drivers/comedi/comedi_fops.c:2178 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_sys---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68335 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()Syzbot identified an issue [1] in pcl818_ai_cancel(), which stems fromthe fact that in case of early device detach via pcl818_detach(),subdevice dev->read_subdev may not have initialized its pointer to&struct comedi_async as intended. Thus, any such dereferencing of&s->async->cmd will lead to general protection fault and kernel crash.Mitigate this problem by removing a call to pcl818_ai_cancel() frompcl818_detach() altogether. This way, if the subdevice setups itssupport for async commands, everything async-related will behandled via subdevice's own ->cancel() function incomedi_device_detach_locked() even before pcl818_detach(). If nosupport for asynchronous commands is provided, there is no needto cancel anything either.[1] Syzbot crash:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]CPU: 1 UID: 0 PID: 6050 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025RIP: 0010:pcl818_ai_cancel+0x69/0x3f0 drivers/comedi/drivers/pcl818.c:762...Call Trace: pcl818_detach+0x66/0xd0 drivers/comedi/drivers/pcl818.c:1115 comedi_device_detach_locked+0x178/0x750 drivers/comedi/drivers.c:207 do_devconfig_ioctl drivers/comedi/comedi_fops.c:848 [inline] comedi_unlocked_ioctl+0xcde/0x1020 drivers/comedi/comedi_fops.c:2178 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline]...

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68336 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:locking/spinlock/debug: Fix data-race in do_raw_write_lockKCSAN reports:BUG: KCSAN: data-race in do_raw_write_lock / do_raw_write_lockwrite (marked) to 0xffff800009cf504c of 4 bytes by task 1102 on cpu 1: do_raw_write_lock+0x120/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkread to 0xffff800009cf504c of 4 bytes by task 1103 on cpu 0: do_raw_write_lock+0x88/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkvalue changed: 0xffffffff -> 0x00000001Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 1103 Comm: kworker/u4:1 6.1.111Commit 1a365e822372 ("locking/spinlock/debug: Fix various data races") hasadressed most of these races, but seems to be not consistent/not complete.>From do_raw_write_lock() only debug_write_lock_after() part has beenconverted to WRITE_ONCE(), but not debug_write_lock_before() part.Do it now.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68337 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corruptedThere's issue when file system corrupted:------------[ cut here ]------------kernel BUG at fs/jbd2/transaction.c:1289!Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-nextRIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0RSP: 0018:ffff888117aafa30 EFLAGS: 00010202RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0Call Trace: __ext4_journal_get_create_access+0x42/0x170 ext4_getblk+0x319/0x6f0 ext4_bread+0x11/0x100 ext4_append+0x1e6/0x4a0 ext4_init_new_dir+0x145/0x1d0 ext4_mkdir+0x326/0x920 vfs_mkdir+0x45c/0x740 do_mkdirat+0x234/0x2f0 __x64_sys_mkdir+0xd6/0x120 do_syscall_64+0x5f/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe above issue occurs with us in errors=continue mode when accompanied bystorage failures. There have been many inconsistencies in the file systemdata.In the case of file system data inconsistency, for example, if the blockbitmap of a referenced block is not set, it can lead to the situation wherea block being committed is allocated and used again. As a result, thefollowing condition will not be satisfied then trigger BUG_ON. Of course,it is entirely possible to construct a problematic image that can triggerthis BUG_ON through specific operations. In fact, I have constructed suchan image and easily reproduced this issue.Therefore, J_ASSERT() holds true only under ideal conditions, but it maynot necessarily be satisfied in exceptional scenarios. Using J_ASSERT()directly in abnormal situations would cause the system to crash, which isclearly not what we want. So here we directly trigger a JBD abort insteadof immediately invoking BUG_ON.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68338 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: microchip: Don't free uninitialized ksz_irqIf something goes wrong at setup, ksz_irq_free() can be called onuninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). Itleads to freeing uninitialized IRQ numbers and/or domains.Use dsa_switch_for_each_user_port_continue_reverse() in the error pathto iterate only over the fully initialized ports.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68341 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:veth: reduce XDP no_direct return section to fix raceAs explain in commit fa349e396e48 ("veth: Fix race with AF_XDP exposingold or uninitialized descriptors") for veth there is a chance afternapi_complete_done() that another CPU can manage start another NAPIinstance running veth_pool(). For NAPI this is correctly handled as thenapi_schedule_prep() check will prevent multiple instances from gettingscheduled, but for the remaining code in veth_pool() this can runconcurrent with the newly started NAPI instance.The problem/race is that xdp_clear_return_frame_no_direct() isn'tdesigned to be nested.Prior to commit 401cb7dae813 ("net: Reference bpf_redirect_info viatask_struct on PREEMPT_RT.") the temporary BPF net contextbpf_redirect_info was stored per CPU, where this wasn't an issue. Sincethis commit the BPF context is stored in 'current' task_struct. Whenrunning veth in threaded-NAPI mode, then the kthread becomes the storagearea. Now a race exists between two concurrent veth_pool() function callsone exiting NAPI and one running new NAPI, both using the same BPF netcontext.Race is when another CPU gets within the xdp_set_return_frame_no_direct()section before exiting veth_pool() calls the clear-functionxdp_clear_return_frame_no_direct().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68345 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi()The acpi_get_first_physical_node() function can return NULL, in whichcase the get_device() function also returns NULL, but this value isthen dereferenced without checking,so add a check to prevent a crash.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68346 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: dice: fix buffer overflow in detect_stream_formats()The function detect_stream_formats() reads the stream_count value directlyfrom a FireWire device without validating it. This can lead toout-of-bounds writes when a malicious device provides a stream_count valuegreater than MAX_STREAMS.Fix by applying the same validation to both TX and RX stream counts indetect_stream_formats().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68348 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: fix memory leak in __blkdev_issue_zero_pagesMove the fatal signal check before bio_alloc() to prevent a memoryleak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending.Previously, the bio was allocated before checking for a fatal signal.If a signal was pending, the code would break out of the loop withoutfreeing or chaining the just-allocated bio, causing a memory leak.This matches the pattern already used in __blkdev_issue_write_zeroes()where the signal check precedes the allocation.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68349 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalidFixes a crash when layout is null during this call stack:write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inodepnfs_set_layoutcommit relies on the lseg refcount to keep the layoutaround. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attemptto reference a null layout.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68351 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix refcount leak in exfat_findFix refcount leaks in `exfat_find` related to `exfat_get_dentry_set`.Function `exfat_get_dentry_set` would increase the reference counter of`es->bh` on success. Therefore, `exfat_put_dentry_set` must be calledafter `exfat_get_dentry_set` to ensure refcount consistency. This patchrelocate two checks to avoid possible leaks.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68352 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: ch341: fix out-of-bounds memory access in ch341_transfer_oneDiscovered by Atuin - Automated Vulnerability Discovery Engine.The 'len' variable is calculated as 'min(32, trans->len + 1)',which includes the 1-byte command header.When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len'as the length is incorrect because:1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context).2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer.Fix this by copying 'len - 1' bytes.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68353 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: vxlan: prevent NULL deref in vxlan_xmit_oneNeither sock4 nor sock6 pointers are guaranteed to be non-NULL invxlan_xmit_one, e.g. if the iface is brought down. This can lead to thefollowing NULL dereference: BUG: kernel NULL pointer dereference, address: 0000000000000010 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:vxlan_xmit_one+0xbb3/0x1580 Call Trace: vxlan_xmit+0x429/0x610 dev_hard_start_xmit+0x55/0xa0 __dev_queue_xmit+0x6d0/0x7f0 ip_finish_output2+0x24b/0x590 ip_output+0x63/0x110Mentioned commits changed the code path in vxlan_xmit_one and as a sideeffect the sock4/6 pointer validity checks in vxlan(6)_get_route werelost. Fix this by adding back checks.Since both commits being fixed were released in the same version (v6.7)and are strongly related, bundle the fixes in a single commit.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68354 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: Protect regulator_supply_alias_list with regulator_list_mutexregulator_supply_alias_list was accessed without any locking inregulator_supply_alias(), regulator_register_supply_alias(), andregulator_unregister_supply_alias(). Concurrent registration,unregistration and lookups can race, leading to:1 use-after-free if an alias entry is removed while being read,2 duplicate entries when two threads register the same alias,3 inconsistent alias mappings observed by consumers.Protect all traversals, insertions and deletions onregulator_supply_alias_list with the existing regulator_list_mutex.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68356 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Prevent recursive memory reclaimFunction new_inode() returns a new inode with inode->i_mapping->gfp_maskset to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, soallocations in that address space can recurse into filesystem memoryreclaim. We don't want that to happen because it can consume asignificant amount of stack memory.Worse than that is that it can also deadlock: for example, in severalplaces, gfs2_unstuff_dinode() is called inside filesystem transactions.This calls filemap_grab_folio(), which can allocate a new folio, whichcan trigger memory reclaim. If memory reclaim recurses into thefilesystem and starts another transaction, a deadlock will ensue.To fix these kinds of problems, prevent memory reclaim from recursinginto filesystem code by making sure that the gfp_mask of inode addressspaces doesn't include __GFP_FS.The "meta" and resource group address spaces were already using GFP_NOFSas their gfp_mask (which doesn't include __GFP_FS). The default valueof GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. Toavoid being overly limiting, use the default value and only knock offthe __GFP_FS flag. I'm not sure if this will actually make adifference, but it also shouldn't hurt.This patch is loosely based on commit ad22c7a043c2 ("xfs: prevent stackoverflows from page cache allocation").Fixes xfstest generic/273.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68358 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix racy bitfield write in btrfs_clear_space_info_full()From the memory-barriers.txt document regarding memory barrier orderingguarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field.btrfs_space_info has a bitfield sharing an underlying word consisting ofthe fields full, chunk_alloc, and flush:struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...Therefore, to be safe from parallel read-modify-writes losing a write toone of the bitfield members protected by a lock, all writes to all thebitfields must use the lock. They almost universally do, except forbtrfs_clear_space_info_full() which iterates over the space_infos andwrites out found->full = 0 without a lock.Imagine that we have one thread completing a transaction in which wefinished deleting a block_group and are thus callingbtrfs_clear_space_info_full() while simultaneously the data reclaimticket infrastructure is running do_async_reclaim_data_space(): T1 T2btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1and now data_sinfo->flush is 1 but the reclaim worker has exited. Thisbreaks the invariant that flush is 0 iff there is no work queued orrunning. Once this invariant is violated, future allocations that gointo __reserve_bytes() will add tickets to space_info->tickets but willsee space_info->flush is set to 1 and not queue the work. After this,they will block forever on the resulting ticket, as it is now impossibleto kick the worker again.I also confirmed by looking at the assembly of the affected kernel thatit is doing RMW operations. For example, to set the flush (3rd) bit to 0,the assembly is: andb $0xfb,0x60(%rbx)and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax)So I think this is really a bug on practical systems. I have observeda number of systems in this exact state, but am currently unable toreproduce it.Rather than leaving this footgun lying around for the future, takeadvantage of the fact that there is room in the struct anyway, and thatit is already quite large and simply change the three bitfield members tobools. This avoids writes to space_info->full having any effect on---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68359 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix double free of qgroup record after failure to add delayed ref headIn the previous code it was possible to incur into a double kfree()scenario when calling add_delayed_ref_head(). This could happen if therecord was reported to already exist in thebtrfs_qgroup_trace_extent_nolock() call, but then there was an errorlater on add_delayed_ref_head(). In this case, sinceadd_delayed_ref_head() returned an error, the caller went to free therecord. Since add_delayed_ref_head() couldn't set this kfree'd pointerto NULL, then kfree() would have acted on a non-NULL 'record' objectwhich was pointing to memory already freed by the callee.The problem comes from the fact that the responsibility to kfree theobject is on both the caller and the callee at the same time. Hence, thefix for this is to shift the ownership of the 'qrecord' object out ofthe add_delayed_ref_head(). That is, we will never attempt to kfree()the given object inside of this function, and will expect the caller toact on the 'qrecord' object on its own. The only exception where the'qrecord' object cannot be kfree'd is if it was inserted into thetracing logic, for which we already have the 'qrecord_inserted_ret'boolean to account for this. Hence, the caller has to kfree the objectonly if add_delayed_ref_head() reports not to have inserted it on thetracing logic.As a side-effect of the above, we must guarantee that'qrecord_inserted_ret' is properly initialized at the start of thefunction, not at the end, and then set when an actual inserthappens. This way we avoid 'qrecord_inserted_ret' having an invalidvalue on an early exit.The documentation from the add_delayed_ref_head() has also been updatedto reflect on the exact ownership of the 'qrecord' object.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68360 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacksMT7996 driver can use both wed and wed_hif2 devices to offload trafficfrom/to the wireless NIC. In the current codebase we assume to alwaysuse the primary wed device in wed callbacks resulting in the followingcrash if the hw runs wed_hif2 (e.g. 6GHz link).[ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a[ 297.464928] Mem abort info:[ 297.467722] ESR = 0x0000000096000005[ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits[ 297.476766] SET = 0, FnV = 0[ 297.479809] EA = 0, S1PTW = 0[ 297.482940] FSC = 0x05: level 1 translation fault[ 297.487809] Data abort info:[ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000[ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000[ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000[ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP[ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0[ 297.723908] Tainted: [O]=OOT_MODULE[ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT)[ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table][ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76][ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80[ 297.757126] sp : ffffffc080fe3ae0[ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7[ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00[ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018[ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000[ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000[ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da[ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200[ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002[ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000[ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8[ 297.831686] Call trace:[ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76][ 297.839254] mtk_wed_flow_remove+0x58/0x80[ 297.843342] mtk_flow_offload_cmd+0x434/0x574[ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40[ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table][ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table][ 297.864463] process_one_work+0x174/0x300[ 297.868465] worker_thread+0x278/0x430[ 297.872204] kthread+0xd8/0xdc[ 297.875251] ret_from_fork+0x10/0x20[ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421)[ 297.884901] ---[ end trace 0000000000000000 ]---Fix the issue detecting the proper wed reference to use running wedcallabacks.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68361 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: limit the level of fs stacking for file-backed mountsOtherwise, it could cause potential kernel stack overflow (e.g., EROFSmounting itself).

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68362 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()The rtl8187_rx_cb() calculates the rx descriptor header addressby subtracting its size from the skb tail pointer.However, it does not validate if the received packet(skb->len from urb->actual_length) is large enough to contain thisheader.If a truncated packet is received, this will lead to a bufferunderflow, reading memory before the start of the skb data area,and causing a kernel panic.Add length checks for both rtl8187 and rtl8187b descriptor headersbefore attempting to access them, dropping the packet cleanly if thecheck fails.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68363 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check skb->transport_header is set in bpf_skb_check_mtuThe bpf_skb_check_mtu helper needs to use skb->transport_header whenthe BPF_MTU_CHK_SEGS flag is used: bpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS)The transport_header is not always set. There is a WARN_ON_ONCEreport when CONFIG_DEBUG_NET is enabled + skb->gso_size is set +bpf_prog_test_run is used:WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skbFor a normal ingress skb (not test_run), skb_reset_transport_headeris performed but there is plan to avoid setting it as described incommit 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()").This patch fixes the bpf helper by checkingskb_transport_header_was_set(). The check is done just beforeskb->transport_header is used, to avoid breaking the existing bpf prog.The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68364 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' justto avoid crashing the whole kernel due to a filesystem corruption.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68365 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: Initialize allocated memory before useKMSAN reports: Multiple uninitialized values detected:- KMSAN: uninit-value in ntfs_read_hdr (3)- KMSAN: uninit-value in bcmp (3)Memory is allocated by __getname(), which is a wrapper forkmem_cache_alloc(). This memory is used before being properlycleared. Change kmem_cache_alloc() to kmem_cache_zalloc() toproperly allocate and clear memory before use.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68366 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config unlock in nbd_genl_connectThere is one use-after-free warning when running NBD_CMD_CONNECT andNBD_CLEAR_SOCK:nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790The issue can be easily reproduced by adding a small delay beforerefcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags);+ printk("before sleep\n");+ mdelay(5 * 1000);+ printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68367 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouseThe following warning appears when running syzkaller, and this issue alsoexists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2The WARNING occurs when two processes concurrently write to the mac-hidemulation sysctl, causing a race condition in mac_hid_toggle_emumouse().Both processes read old_val=0, then both try to register the input handler,leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock()Fix this by moving the old_val read inside the mutex lock region.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68368 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md: init bioset in mddev_initIO operations may be needed before md_run(), such as updating metadataafter writing sysfs. Without bioset, this triggers a NULL pointerdereference as below: BUG: kernel NULL pointer dereference, address: 0000000000000020 Call Trace: md_update_sb+0x658/0xe00 new_level_store+0xc5/0x120 md_attr_store+0xc9/0x1e0 sysfs_kf_write+0x6f/0xa0 kernfs_fop_write_iter+0x141/0x2a0 vfs_write+0x1fc/0x5a0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x2818/0x2880 do_syscall_64+0xa9/0x580 entry_SYSCALL_64_after_hwframe+0x4b/0x53Reproducer``` mdadm -CR /dev/md0 -l1 -n2 /dev/sd[cd] echo inactive > /sys/block/md0/md/array_state echo 10 > /sys/block/md0/md/new_level```mddev_init() can only be called once per mddev, no need to test if biosethas been initialized anymore.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68371 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Fix device resources accessed after device removalCorrect possible race conditions during device removal.Previously, a scheduled work item to reset a LUN could still executeafter the device was removed, leading to use-after-free and otherresource access issues.This race condition occurs because the abort handler may schedule a LUNreset concurrently with device removal via sdev_destroy(), leading touse-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68372 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config put in recv_workThere is one uaf issue in recv_work when running NBD_CLEAR_SOCK andNBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFOr only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFCommit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying thewaiter") moved nbd_config_put() to run before waking up the waiter inrecv_work, in order to ensure that nbd_start_device_ioctl() would notbe woken up while nbd->task_recv was still uncleared.However, in nbd_start_device_ioctl(), after being woken up it explicitlycalls flush_workqueue() to make sure all current works are finished.Therefore, there is no need to move the config put ahead of the wakeup.Move nbd_config_put() to the end of recv_work, so that the reference isheld for the whole lifetime of the worker thread. This makes sure theconfig cannot be freed while recv_work is still running, even if clear+ reconfigure interleave.In addition, we don't need to worry about recv_work dropping the lastnbd_put (which causes deadlock):path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_workpath B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68374 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md: fix rcu protection in md_wakeup_threadWe attempted to use RCU to protect the pointer 'thread', but directlypassed the value when calling md_wakeup_thread(). This means that theRCU pointer has been acquired before rcu_read_lock(), which rendersrcu_read_lock() ineffective and could lead to a use-after-free.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68376 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:coresight: ETR: Fix ETR buffer use-after-free issueWhen ETR is enabled as CS_MODE_SYSFS, if the buffer size is changedand enabled again, currently sysfs_buf will point to the newlyallocated memory(buf_new) and free the old memory(buf_old). But theetr_buf that is being used by the ETR remains pointed to buf_old, notupdated to buf_new. In this case, it will result in a memoryuse-after-free issue.Fix this by checking ETR's mode before updating and releasing buf_old,if the mode is CS_MODE_SYSFS, then skip updating and releasing it.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68378 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stackmap overflow check in __bpf_get_stackid()Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68379 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix null deref on srq->rq.queue after resize failureA NULL pointer dereference can occur in rxe_srq_chk_attr() whenibv_modify_srq() is invoked twice in succession under certain errorconditions. The first call may fail in rxe_queue_resize(), which leadsrxe_srq_from_attr() to set srq->rq.queue = NULL. The second call thentriggers a crash (null deref) when accessingsrq->rq.queue->buf->index_mask.Call Trace:rxe_modify_srq+0x170/0x480 [rdma_rxe]? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]? tryinc_node_nr_active+0xe6/0x150? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]? __pfx___raw_spin_lock_irqsave+0x10/0x10? __pfx_do_vfs_ioctl+0x10/0x10? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]__x64_sys_ioctl+0x138/0x1c0do_syscall_64+0x82/0x250? fdget_pos+0x58/0x4c0? ksys_write+0xf3/0x1c0? __pfx_ksys_write+0x10/0x10? do_syscall_64+0xc8/0x250? __pfx_vm_mmap_pgoff+0x10/0x10? fget+0x173/0x230? fput+0x2a/0x80? ksys_mmap_pgoff+0x224/0x4c0? do_syscall_64+0xc8/0x250? do_user_addr_fault+0x37b/0xfe0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68380 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix peer HE MCS assignmentIn ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent tofirmware as receive MCS while peer's receive MCS sent as transmit MCS,which goes against firmwire's definition.While connecting to a misbehaved AP that advertises 0xffff (meaning notsupported) for 160 MHz transmit MCS map, firmware crashes due to 0xffffis assigned to he_mcs->rx_mcs_set field. Ext Tag: HE Capabilities [...] Supported HE-MCS and NSS Set [...] Rx and Tx MCS Maps 160 MHz [...] Tx HE-MCS Map 160 MHz: 0xffffSwap the assignment to fix this issue.As the HE rate control mask is meant to limit our own transmit MCS, itneeds to go via he_mcs->rx_mcs_set field. With the aforementioned swappingdone, change is needed as well to apply it to the peer's receive MCS.Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68431 Severity: Moderate CVSS3 score: 5.5

Description: libheif is an HEIF and AVIF file format decoder and encoder. Prior to version 1.21.0, a crafted HEIF that exercises the overlay image item path triggers a heap buffer over-read in `HeifPixelImage::overlay()`. The function computes a negative row length (likely from an unclipped overlay rectangle or invalid offsets), which then underflows when converted to `size_t` and is passed to `memcpy`, causing a very large read past the end of the source plane and a crash. Version 1.21.0 contains a patch. As a workaround, avoid decoding images using `iovl` overlay boxes.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libheif1 < 1.19.7-160000.3.1 (version in image is 1.19.7-160000.2.2).

CVE-2025-68724 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_idUse check_add_overflow() to guard against potential integer overflowswhen adding the binary blob lengths and the size of an asymmetric_key_idstructure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents apossible buffer overflow when copying data from potentially maliciousX.509 certificate fields that can be arbitrarily large, such as ASN.1INTEGER serial numbers, issuer names, etc.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68725 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Do not let BPF test infra emit invalid GSO types to stackYinhao et al. reported that their fuzzer tool was able to trigger askb_warn_bad_offload() from netif_skb_features() -> gso_features_check().When a BPF program - triggered via BPF test infra - pushes the packetto the loopback device via bpf_clone_redirect() then mentioned offloadwarning can be seen. GSO-related features are then rightfully disabled.We get into this situation due to convert___skb_to_skb() settinggso_segs and gso_size but not gso_type. Technically, it makes sensethat this warning triggers since the GSO properties are malformed dueto the gso_type. Potentially, the gso_type could be marked non-trustworthythrough setting it at least to SKB_GSO_DODGY without any other specificassumptions, but that also feels wrong given we should not go furtherinto the GSO engine in the first place.The checks were added in 121d57af308d ("gso: validate gso_type in GSOhandlers") because there were malicious (syzbot) senders that combinea protocol with a non-matching gso_type. If we would want to drop suchpackets, gso_features_check() currently only returns feature flags vianetif_skb_features(), so one location for potentially dropping such skbscould be validate_xmit_unreadable_skb(), but then otoh it would bean additional check in the fast-path for a very corner case. Givenbpf_clone_redirect() is the only place where BPF test infra could emitsuch packets, lets reject them right there.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68727 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ntfs3: Fix uninit buffer allocated by __getname()Fix uninit errors caused after buffer allocation given to 'de'; byinitializing the buffer with zeroes. The fix was found by using KMSAN.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68728 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ntfs3: fix uninit memory after failed mi_read in mi_format_newFix a KMSAN un-init bug found by syzkaller.ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not beuptodate. We do not bring the buffer uptodate before setting it asuptodate. If the buffer were to not be uptodate, it could mean adding abuffer with un-init data to the mi record. Attempting to load that recordwill trigger KMSAN.Avoid this by setting the buffer as uptodate, if it's not already, byoverwriting it.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68730 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()Don't add BO to the vdev->bo_list in ivpu_gem_create_object().When failure happens inside drm_gem_shmem_create(), the BO is notfully created and ivpu_gem_bo_free() callback will not be calledcausing a deleted BO to be left on the list.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68733 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smack: fix bug: unprivileged task can create labelsIf an unprivileged task is allowed to relabel itself(/smack/relabel-self is not empty),it can freely create new labels by writing theirnames into own /proc/PID/attr/smack/currentThis occurs because do_setattr() importsthe provided label in advance,before checking "relabel-self" list.This change ensures that the "relabel-self" listis checked before importing the label.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68740 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ima: Handle error code returned by ima_filter_rule_match()In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due tothe rule being NULL, the function incorrectly skips the 'if (!rc)' checkand sets 'result = true'. The LSM rule is considered a match, causingextra files to be measured by IMA.This issue can be reproduced in the following scenario:After unloading the SELinux policy module via 'semodule -d', if an IMAmeasurement is triggered before ima_lsm_rules is updated,in ima_match_rules(), the first call to ima_filter_rule_match() returns-ESTALE. This causes the code to enter the 'if (rc == -ESTALE &&!rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. Inima_lsm_copy_rule(), since the SELinux module has been removed, the rulebecomes NULL, and the second call to ima_filter_rule_match() returns-ENOENT. This bypasses the 'if (!rc)' check and results in a false match.Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that errorcodes like -ENOENT do not bypass the check and accidentally result in asuccessful match.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68753 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: firewire-motu: add bounds check in put_user loop for DSP eventsIn the DSP event handling code, a put_user() loop copies event data.When the user buffer size is not aligned to 4 bytes, it could overwritebeyond the buffer boundary.Fix by adding a bounds check before put_user().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68757 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vgem-fence: Fix potential deadlock on releaseA timer that expires a vgem fence automatically in 10 seconds is nowreleased with timer_delete_sync() from fence->ops.release() called on lastdma_fence_put(). In some scenarios, it can run in IRQ context, which isnot safe unless TIMER_IRQSAFE is used. One potentially risky scenario wasdemonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, whileworking on new IGT subtests syncobj_timeline@stress-* as user spacereplacements of some problematic test cases of a dma-fence-chain selftest[1].[117.004338] ================================[117.004340] WARNING: inconsistent lock state[117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U[117.004346] --------------------------------[117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.[117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes:[117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190[117.004361] {HARDIRQ-ON-W} state was registered at:[117.004363] lock_acquire+0xc4/0x2e0[117.004366] call_timer_fn+0x80/0x2a0[117.004368] __run_timers+0x231/0x310[117.004370] run_timer_softirq+0x76/0xe0[117.004372] handle_softirqs+0xd4/0x4d0[117.004375] __irq_exit_rcu+0x13f/0x160[117.004377] irq_exit_rcu+0xe/0x20[117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0[117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20[117.004385] cpuidle_enter_state+0x12b/0x8a0[117.004388] cpuidle_enter+0x2e/0x50[117.004393] call_cpuidle+0x22/0x60[117.004395] do_idle+0x1fd/0x260[117.004398] cpu_startup_entry+0x29/0x30[117.004401] start_secondary+0x12d/0x160[117.004404] common_startup_64+0x13e/0x141[117.004407] irq event stamp: 2282669[117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80[117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0[117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18[117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160[117.004426]other info that might help us debug this:[117.004429] Possible unsafe locking scenario:[117.004432] CPU0[117.004433] ----[117.004434] lock((&fence->timer));[117.004436] [117.004438] lock((&fence->timer));[117.004440] *** DEADLOCK ***[117.004443] 1 lock held by swapper/0/0:[117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0[117.004450]stack backtrace:[117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary)[117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER[117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023[117.004456] Call Trace:[117.004456] [117.004457] dump_stack_lvl+0x91/0xf0[117.004460] dump_stack+0x10/0x20[117.004461] print_usage_bug.part.0+0x260/0x360[117.004463] mark_lock+0x76e/0x9c0[117.004465] ? register_lock_class+0x48/0x4a0[117.004467] __lock_acquire+0xbc3/0x2860[117.004469] lock_acquire+0xc4/0x2e0[117.004470] ? __timer_delete_sync+0x4b/0x190[117.004472] ? __timer_delete_sync+0x4b/0x190[117.004473] __timer_delete_sync+0x68/0x190[117.004474] ? __timer_delete_sync+0x4b/0x190[117.004475] timer_delete_sync+0x10/0x20[117.004476] vgem_fence_release+0x19/0x30 [vgem][117.004478] dma_fence_release+0xc1/0x3b0[117.004480] ? dma_fence_release+0xa1/0x3b0[117.004481] dma_fence_chain_release+0xe7/0x130[117.004483] dma_fence_release+0xc1/0x3b0[117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80[117.004485] dma_fence_chain_irq_work+0x59/0x80[117.004487] irq_work_single+0x75/0xa0[117.004490] irq_work_r---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68759 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMAallocations in a loop. When an allocation fails, the previouslysuccessful allocations are not freed on exit.Fix that by jumping to err_free_rings label on error, which callsrtl8180_free_rx_ring() to free the allocations. Remove the free ofrx_ring in rtl8180_init_rx_ring() error path, and set the freedpriv->rx_buf entry to null, to avoid double free.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68765 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If thesubsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the functionreturns an error without freeing sskb, leading to a memory leak.Fix this by calling dev_kfree_skb() on sskb in the error handling pathto ensure it is properly released.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68771 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix kernel BUG in ocfs2_find_victim_chainsyzbot reported a kernel BUG in ocfs2_find_victim_chain() because the`cl_next_free_rec` field of the allocation chain list (next free slot inthe chain list) is 0, triggring the BUG_ON(!cl->cl_next_free_rec)condition in ocfs2_find_victim_chain() and panicking the kernel.To fix this, an if condition is introduced in ocfs2_claim_suballoc_bits(),just before calling ocfs2_find_victim_chain(), the code block in it beingexecuted when either of the following conditions is true:1. `cl_next_free_rec` is equal to 0, indicating that there are no freechains in the allocation chain list2. `cl_next_free_rec` is greater than `cl_count` (the total number ofchains in the allocation chain list)Either of them being true is indicative of the fact that there are nochains left for usage.This is addressed using ocfs2_error(), which printsthe error log for debugging purposes, rather than panicking the kernel.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68780 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: only set free_cpus for online runqueuesCommit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpusto reflect rd->online") introduced the cpudl_set/clear_freecpufunctions to allow the cpu_dl::free_cpus mask to be manipulatedby the deadline scheduler class rq_on/offline callbacks so themask would also reflect this state.Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_maskfrom cpudl_find()") removed the check of the cpu_active_mask tosave some processing on the premise that the cpudl::free_cpusmask already reflected the runqueue online state.Unfortunately, there are cases where it is possible for thecpudl_clear function to set the free_cpus bit for a CPU when thedeadline runqueue is offline. When this occurs while a CPU isconnected to the default root domain the flag may retain the badstate after the CPU has been unplugged. Later, a different CPUthat is transitioning through the default root domain may push adeadline task to the powered down CPU when cpudl_find sees itsfree_cpus bit is set. If this happens the task will not have theopportunity to run.One example is outlined here:https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.comAnother occurs when the last deadline task is migrated from aCPU that has an offlined runqueue. The dequeue_task member ofthe deadline scheduler class will eventually call cpudl_clearand set the free_cpus bit for the CPU.This commit modifies the cpudl_clear function to be aware of theonline state of the deadline runqueue so that the free_cpus maskcan be updated appropriately.It is no longer necessary to manage the mask outside of thecpudl_set/clear functions so the cpudl_set/clear_freecpufunctions are removed. In addition, since the free_cpus mask isnow only updated under the cpudl lock the code was changed touse the non-atomic __cpumask functions.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68782 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Reset t_task_cdb pointer in error caseIf allocation of cmd->t_task_cdb fails, it remains NULL but is laterdereferenced in the 'err' path.In case of error, reset NULL t_task_cdb value to point at the defaultfixed-size buffer.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netrom: Fix memory leak in nr_sendmsg()syzbot reported a memory leak [1].When function sock_alloc_send_skb() return NULL in nr_output(), theoriginal skb is not freed, which was allocated in nr_sendmsg(). Fix thisby freeing it before return.[1]BUG: memory leakunreferenced object 0xffff888129f35500 (size 240): comm "syz.0.17", pid 6119, jiffies 4294944652 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 10 52 28 81 88 ff ff ..........R(.... backtrace (crc 1456a3e4): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4983 [inline] slab_alloc_node mm/slub.c:5288 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5340 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/skbuff.c:6671 sock_alloc_send_pskb+0x379/0x3e0 net/core/sock.c:2965 sock_alloc_send_skb include/net/sock.h:1859 [inline] nr_sendmsg+0x287/0x450 net/netrom/af_netrom.c:1105 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x293/0x2a0 net/socket.c:1195 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0x143/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68797 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:char: applicom: fix NULL pointer dereference in ac_ioctlDiscovered by Atuin - Automated Vulnerability Discovery Engine.In ac_ioctl, the validation of IndexCard and the check for a validRamIO pointer are skipped when cmd is 6. However, the functionunconditionally executes readb(apbs[IndexCard].RamIO + VERS) at theend.If cmd is 6, IndexCard may reference a board that does not exist(where RamIO is NULL), leading to a NULL pointer dereference.Fix this by skipping the readb access when cmd is 6, as thiscommand is a global information query and does not target a specificboard context.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68809 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: vfs: fix race on m_flags in vfs_cacheksmbd maintains delete-on-close and pending-delete state inksmbd_inode->m_flags. In vfs_cache.c this field is accessed underinconsistent locking: some paths read and modify m_flags underci->m_lock while others do so without taking the lock at all.Examples: - ksmbd_query_inode_status() and __ksmbd_inode_close() use ci->m_lock when checking or updating m_flags. - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close() used to read and modify m_flags without ci->m_lock.This creates a potential data race on m_flags when multiple threadsopen, close and delete the same file concurrently. In the worst casedelete-on-close and pending-delete bits can be lost or observed in aninconsistent state, leading to confusing delete semantics (files thatstay on disk after delete-on-close, or files that disappear while stillin use).Fix it by: - Making ksmbd_query_inode_status() look at m_flags under ci->m_lock after dropping inode_hash_lock. - Adding ci->m_lock protection to all helpers that read or modify m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()). - Keeping the existing ci->m_lock protection in __ksmbd_inode_close(), and moving the actual unlink/xattr removal outside the lock.This unifies the locking around m_flags and removes the data race whilepreserving the existing delete-on-close behaviour.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68810 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Disallow toggling KVM_MEM_GUEST_MEMFD on an existing memslotReject attempts to disable KVM_MEM_GUEST_MEMFD on a memslot that wasinitially created with a guest_memfd binding, as KVM doesn't supporttoggling KVM_MEM_GUEST_MEMFD on existing memslots. KVM prevents enablingKVM_MEM_GUEST_MEMFD, but doesn't prevent clearing the flag.Failure to reject the new memslot results in a use-after-free due to KVMnot unbinding from the guest_memfd instance. Unbinding on a FLAGS_ONLYchange is easy enough, and can/will be done as a hardening measure (inanticipation of KVM supporting dirty logging on guest_memfd at some point),but fixing the use-after-free would only address the immediate symptom. ================================================================== BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x362/0x400 [kvm] Write of size 8 at addr ffff8881111ae908 by task repro/745 CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5c0 kasan_report+0xb4/0xe0 kvm_gmem_release+0x362/0x400 [kvm] __fput+0x2fa/0x9d0 task_work_run+0x12c/0x200 do_exit+0x6ae/0x2100 do_group_exit+0xa8/0x230 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0x737/0x740 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f581f2eac31 Allocated by task 745 on cpu 6 at 9.746971s: kasan_save_stack+0x20/0x40 kasan_save_track+0x13/0x50 __kasan_kmalloc+0x77/0x90 kvm_set_memory_region.part.0+0x652/0x1110 [kvm] kvm_vm_ioctl+0x14b0/0x3290 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 745 on cpu 6 at 9.747467s: kasan_save_stack+0x20/0x40 kasan_save_track+0x13/0x50 __kasan_save_free_info+0x37/0x50 __kasan_slab_free+0x3b/0x60 kfree+0xf5/0x440 kvm_set_memslot+0x3c2/0x1160 [kvm] kvm_set_memory_region.part.0+0x86a/0x1110 [kvm] kvm_vm_ioctl+0x14b0/0x3290 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0x5b/0x900 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68811 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: use rc_pageoff for memcpy byte offsetsvc_rdma_copy_inline_range added rc_curpage (page index) to the pagebase instead of the byte offset rc_pageoff. Use rc_pageoff so copiesland within the current page.Found by ZeroPath (https://zeropath.com)

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68814 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix filename leak in __io_openat_prep() __io_openat_prep() allocates a struct filename using getname(). However,for the condition of the file being installed in the fixed file table aswell as having O_CLOEXEC flag set, the function returns early. At thatpoint, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this,the memory for the newly allocated struct filename is not cleaned up,causing a memory leak.Fix this by setting the REQ_F_NEED_CLEANUP for the request just after thesuccessful getname() call, so that when the request is torn down, thefilename will be cleaned up, along with other resources needing cleanup.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68815 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: Remove drr class from the active list if it changes to strictWhenever a user issues an ets qdisc change command, transforming adrr class into a strict one, the ets code isn't checking whether thatclass was in the active list and removing it. This means that, if auser changes a strict class (which was in the active list) back to a drrone, that class will be added twice to the active list [1].Doing so with the following commands:tc qdisc add dev lo root handle 1: ets bands 2 strict 1tc qdisc add dev lo parent 1:2 handle 20: \ tbf rate 8bit burst 100b latency 1stc filter add dev lo parent 1: basic classid 1:2ping -c1 -W0.01 -s 56 127.0.0.1tc qdisc change dev lo root handle 1: ets bands 2 strict 2tc qdisc change dev lo root handle 1: ets bands 2 strict 1ping -c1 -W0.01 -s 56 127.0.0.1Will trigger the following splat with list debug turned on:[ 59.279014][ T365] ------------[ cut here ]------------[ 59.279452][ T365] list_add double add: new=ffff88801d60e350, prev=ffff88801d60e350, next=ffff88801d60e2c0.[ 59.280153][ T365] WARNING: CPU: 3 PID: 365 at lib/list_debug.c:35 __list_add_valid_or_report+0x17f/0x220[ 59.280860][ T365] Modules linked in:[ 59.281165][ T365] CPU: 3 UID: 0 PID: 365 Comm: tc Not tainted 6.18.0-rc7-00105-g7e9f13163c13-dirty #239 PREEMPT(voluntary)[ 59.281977][ T365] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011[ 59.282391][ T365] RIP: 0010:__list_add_valid_or_report+0x17f/0x220[ 59.282842][ T365] Code: 89 c6 e8 d4 b7 0d ff 90 0f 0b 90 90 31 c0 e9 31 ff ff ff 90 48 c7 c7 e0 a0 22 9f 48 89 f2 48 89 c1 4c 89 c6 e8 b2 b7 0d ff 90 <0f> 0b 90 90 31 c0 e9 0f ff ff ff 48 89 f7 48 89 44 24 10 4c 89 44...[ 59.288812][ T365] Call Trace:[ 59.289056][ T365] [ 59.289224][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.289546][ T365] ets_qdisc_change+0xd2b/0x1e80[ 59.289891][ T365] ? __lock_acquire+0x7e7/0x1be0[ 59.290223][ T365] ? __pfx_ets_qdisc_change+0x10/0x10[ 59.290546][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.290898][ T365] ? __mutex_trylock_common+0xda/0x240[ 59.291228][ T365] ? __pfx___mutex_trylock_common+0x10/0x10[ 59.291655][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.291993][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.292313][ T365] ? trace_contention_end+0xc8/0x110[ 59.292656][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.293022][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.293351][ T365] tc_modify_qdisc+0x63a/0x1cf0Fix this by always checking and removing an ets class from the active listwhen changing it to strict.[1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/net/sched/sch_ets.c?id=ce052b9402e461a9aded599f5b47e76bc727f7de#n663

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68816 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fw_tracer, Validate format string parametersAdd validation for format string parameters in the firmware tracer toprevent potential security vulnerabilities and crashes from malformedformat strings received from firmware.The firmware tracer receives format strings from the device firmware anduses them to format trace messages. Without proper validation, badfirmware could provide format strings with invalid format specifiers(e.g., %s, %p, %n) that could lead to crashes, or other undefinedbehavior.Add mlx5_tracer_validate_params() to validate that all format specifiersin trace strings are limited to safe integer/hex formats (%x, %d, %i,%u, %llx, %lx, etc.). Reject strings containing other format types thatcould be used to access arbitrary memory or cause crashes.Invalid format strings are added to the trace output for visibility with"BAD_FORMAT: " prefix.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68817 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrencyUnder high concurrency, A tree-connection object (tcon) is freed ona disconnect path while another path still holds a reference and laterexecutes *_put()/write on it.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68818 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.The commit being reverted added code to __qla2x00_abort_all_cmds() tocall sp->done() without holding a spinlock. But unlike the older codebelow it, this new code failed to check sp->cmd_type and just assumedTYPE_SRB, which results in a jump to an invalid pointer in target-modewith TYPE_TGT_CMD:qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success 0000000009f7a79bqla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no bufferqla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event 0x8002 occurredqla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery - ha=0000000058183fda.BUG: kernel NULL pointer dereference, address: 0000000000000000PF: supervisor instruction fetch in kernel modePF: error_code(0x0010) - not-present pagePGD 0 P4D 0Oops: 0010 [#1] SMPCPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early withinlock") added the spinlock back, because not having the lock caused arace and a crash. But qla2x00_abort_srb() in the switch below alreadychecks for qla2x00_chip_is_down() and handles it the same way, so thecode above the switch is now redundant and still buggy in target-mode.Remove it.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68821 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fuse: fix readahead reclaim deadlockCommit e26ee4efbc79 ("fuse: allocate ff->release_args only if release isneeded") skips allocating ff->release_args if the server does notimplement open. However in doing so, fuse_prepare_release() now skipsgrabbing the reference on the inode, which makes it possible for aninode to be evicted from the dcache while there are inflight readaheadrequests. This causes a deadlock if the server triggers reclaim whileservicing the readahead request and reclaim attempts to evict the inodeof the file being read ahead. Since the folio is locked duringreadahead, when reclaim evicts the fuse inode and fuse_evict_inode()attempts to remove all folios associated with the inode from the pagecache (truncate_inode_pages_range()), reclaim will block forever waitingfor the lock since readahead cannot relinquish the lock because it isitself blocked in reclaim:>>> stack_trace(1504735) folio_wait_bit_common (mm/filemap.c:1308:4) folio_lock (./include/linux/pagemap.h:1052:3) truncate_inode_pages_range (mm/truncate.c:336:10) fuse_evict_inode (fs/fuse/inode.c:161:2) evict (fs/inode.c:704:3) dentry_unlink_inode (fs/dcache.c:412:3) __dentry_kill (fs/dcache.c:615:3) shrink_kill (fs/dcache.c:1060:12) shrink_dentry_list (fs/dcache.c:1087:3) prune_dcache_sb (fs/dcache.c:1168:2) super_cache_scan (fs/super.c:221:10) do_shrink_slab (mm/shrinker.c:435:9) shrink_slab (mm/shrinker.c:626:10) shrink_node (mm/vmscan.c:5951:2) shrink_zones (mm/vmscan.c:6195:3) do_try_to_free_pages (mm/vmscan.c:6257:3) do_swap_page (mm/memory.c:4136:11) handle_pte_fault (mm/memory.c:5562:10) handle_mm_fault (mm/memory.c:5870:9) do_user_addr_fault (arch/x86/mm/fault.c:1338:10) handle_page_fault (arch/x86/mm/fault.c:1481:3) exc_page_fault (arch/x86/mm/fault.c:1539:2) asm_exc_page_fault+0x22/0x27Fix this deadlock by allocating ff->release_args and grabbing thereference on the inode when preparing the file for release even if theserver does not implement open. The inode reference will be dropped whenthe last reference on the fuse file is dropped (see fuse_file_put() ->fuse_release_end()).

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68823 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ublk: fix deadlock when reading partition tableWhen one process(such as udev) opens ublk block device (e.g., to readthe partition table via bdev_open()), a deadlock[1] can occur:1. bdev_open() grabs disk->open_mutex2. The process issues read I/O to ublk backend to read partition table3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request() runs bio->bi_end_io() callbacks4. If this triggers fput() on file descriptor of ublk block device, the work may be deferred to current task's task work (see fput() implementation)5. This eventually calls blkdev_release() from the same context6. blkdev_release() tries to grab disk->open_mutex again7. Deadlock: same task waiting for a mutex it already holdsThe fix is to run blk_update_request() and blk_mq_end_request() with bottomhalves disabled. This forces blkdev_release() to run in kernel work-queuecontext instead of current task work context, and allows ublk server to makeforward progress, and avoids the deadlock.[axboe: rewrite comment in ublk]

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71064 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: using the num_tqps in the vf driver to apply for resourcesCurrently, hdev->htqp is allocated using hdev->num_tqps, and kinfo->tqpis allocated using kinfo->num_tqps. However, kinfo->num_tqps is set tomin(new_tqps, hdev->num_tqps); Therefore, kinfo->num_tqps may be smallerthan hdev->num_tqps, which causes some hdev->htqp[i] to remainuninitialized in hclgevf_knic_setup().Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps,ensuring that the lengths of hdev->htqp and kinfo->tqp are consistentand that all elements are properly initialized.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71066 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: Always remove class from active list before deleting in ets_qdisc_changezdi-disclosures@trendmicro.com says:The vulnerability is a race condition between `ets_qdisc_dequeue` and`ets_qdisc_change`. It leads to UAF on `struct Qdisc` object.Attacker requires the capability to create new user and network namespacein order to trigger the bug.See my additional commentary at the end of the analysis.Analysis:static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt, struct netlink_ext_ack *extack){... // (1) this lock is preventing .change handler (`ets_qdisc_change`) //to race with .dequeue handler (`ets_qdisc_dequeue`) sch_tree_lock(sch); for (i = nbands; i < oldbands; i++) { if (i >= q->nstrict && q->classes[i].qdisc->q.qlen) list_del_init(&q->classes[i].alist); qdisc_purge_queue(q->classes[i].qdisc); } WRITE_ONCE(q->nbands, nbands); for (i = nstrict; i < q->nstrict; i++) { if (q->classes[i].qdisc->q.qlen) { // (2) the class is added to the q->active list_add_tail(&q->classes[i].alist, &q->active); q->classes[i].deficit = quanta[i]; } } WRITE_ONCE(q->nstrict, nstrict); memcpy(q->prio2band, priomap, sizeof(priomap)); for (i = 0; i < q->nbands; i++) WRITE_ONCE(q->classes[i].quantum, quanta[i]); for (i = oldbands; i < q->nbands; i++) { q->classes[i].qdisc = queues[i]; if (q->classes[i].qdisc != &noop_qdisc) qdisc_hash_add(q->classes[i].qdisc, true); } // (3) the qdisc is unlocked, now dequeue can be called in parallel // to the rest of .change handler sch_tree_unlock(sch); ets_offload_change(sch); for (i = q->nbands; i < oldbands; i++) { // (4) we're reducing the refcount for our class's qdisc and // freeing it qdisc_put(q->classes[i].qdisc); // (5) If we call .dequeue between (4) and (5), we will have // a strong UAF and we can control RIP q->classes[i].qdisc = NULL; WRITE_ONCE(q->classes[i].quantum, 0); q->classes[i].deficit = 0; gnet_stats_basic_sync_init(&q->classes[i].bstats); memset(&q->classes[i].qstats, 0, sizeof(q->classes[i].qstats)); } return 0;}Comment:This happens because some of the classes have their qdiscs assigned toNULL, but remain in the active list. This commit fixes this issue by alwaysremoving the class from the active list before deleting and freeing itsassociated qdiscReproducer Steps(trimmed version of what was sent by zdi-disclosures@trendmicro.com)```DEV="${DEV:-lo}"ROOT_HANDLE="${ROOT_HANDLE:-1:}"BAND2_HANDLE="${BAND2_HANDLE:-20:}" # child under 1:2PING_BYTES="${PING_BYTES:-48}"PING_COUNT="${PING_COUNT:-200000}"PING_DST="${PING_DST:-127.0.0.1}"SLOW_TBF_RATE="${SLOW_TBF_RATE:-8bit}"SLOW_TBF_BURST="${SLOW_TBF_BURST:-100b}"SLOW_TBF_LAT="${SLOW_TBF_LAT:-1s}"cleanup() { tc qdisc del dev "$DEV" root 2>/dev/null}trap cleanup EXITip link set "$DEV" uptc qdisc del dev "$DEV" root 2>/dev/null || truetc qdisc add dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2tc qdisc add dev "$DEV" parent 1:2 handle "$BAND2_HANDLE" \ tbf rate "$SLOW_TBF_RATE" burst "$SLOW_TBF_BURST" latency "$SLOW_TBF_LAT"tc filter add dev "$DEV" parent 1: protocol all prio 1 u32 match u32 0 0 flowid 1:2tc -s qdisc ls dev $DEVping -I "$DEV" -f -c "$PING_COUNT" -s "$PING_BYTES" -W 0.001 "$PING_DST" \ >/dev/null 2>&1 &tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 0tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2tc -s qdisc ls dev $DEVtc qdisc del dev "$DEV" parent ---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71067 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ntfs: set dummy blocksize to read boot_block when mountingWhen mounting, sb->s_blocksize is used to read the boot_block withoutbeing defined or validated. Set a dummy blocksize before attempting toread the boot_block.The issue can be triggered with the following syz reproducer: mkdirat(0xffffffffffffff9c, &(0x7f0000000080)='./file1\x00', 0x0) r4 = openat$nullb(0xffffffffffffff9c, &(0x7f0000000040), 0x121403, 0x0) ioctl$FS_IOC_SETFLAGS(r4, 0x40081271, &(0x7f0000000980)=0x4000) mount(&(0x7f0000000140)=@nullb, &(0x7f0000000040)='./cgroup\x00', &(0x7f0000000000)='ntfs3\x00', 0x2208004, 0x0) syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0)Here, the ioctl sets the bdev block size to 16384. During mount,get_tree_bdev_flags() calls sb_set_blocksize(sb, block_size(bdev)),but since block_size(bdev) > PAGE_SIZE, sb_set_blocksize() leavessb->s_blocksize at zero.Later, ntfs_init_from_boot() attempts to read the boot_block whilesb->s_blocksize is still zero, which triggers the bug.[almaz.alexandrovich@paragon-software.com: changed comment style, addedreturn value handling]

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71068 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: bound check rq_pages index in inline pathsvc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] withoutverifying rc_curpage stays within the allocated page array. Add guardsbefore the first use and after advancing to a new page.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: invalidate dentry cache on failed whiteout creationF2FS can mount filesystems with corrupted directory depth values thatget runtime-clamped to MAX_DIR_HASH_DEPTH. When RENAME_WHITEOUToperations are performed on such directories, f2fs_rename performsdirectory modifications (updating target entry and deleting sourceentry) before attempting to add the whiteout entry via f2fs_add_link.If f2fs_add_link fails due to the corrupted directory structure, thefunction returns an error to VFS, but the partial directorymodifications have already been committed to disk. VFS assumes theentire rename operation failed and does not update the dentry cache,leaving stale mappings.In the error path, VFS does not call d_move() to update the dentrycache. This results in new_dentry still pointing to the old inode(new_inode) which has already had its i_nlink decremented to zero.The stale cache causes subsequent operations to incorrectly referencethe freed inode.This causes subsequent operations to use cached dentry information thatno longer matches the on-disk state. When a second rename targets thesame entry, VFS attempts to decrement i_nlink on the stale inode, whichmay already have i_nlink=0, triggering a WARNING in drop_nlink().Example sequence:1. First rename (RENAME_WHITEOUT): file2 -> file1 - f2fs updates file1 entry on disk (points to inode 8) - f2fs deletes file2 entry on disk - f2fs_add_link(whiteout) fails (corrupted directory) - Returns error to VFS - VFS does not call d_move() due to error - VFS cache still has: file1 -> inode 7 (stale!) - inode 7 has i_nlink=0 (already decremented)2. Second rename: file3 -> file1 - VFS uses stale cache: file1 -> inode 7 - Tries to drop_nlink on inode 7 (i_nlink already 0) - WARNING in drop_nlink()Fix this by explicitly invalidating old_dentry and new_dentry whenf2fs_add_link fails during whiteout creation. This forces VFS torefresh from disk on subsequent operations, ensuring cache consistencyeven when the rename partially succeeds.Reproducer:1. Mount F2FS image with corrupted i_current_depth2. renameat2(file2, file1, RENAME_WHITEOUT)3. renameat2(file3, file1, 0)4. System triggers WARNING in drop_nlink()

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71072 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:shmem: fix recovery on rename failuresmaple_tree insertions can fail if we are seriously short on memory;simple_offset_rename() does not recover well if it runs into that.The same goes for simple_offset_rename_exchange().Moreover, shmem_whiteout() expects that if it succeeds, the caller willprogress to d_move(), i.e. that shmem_rename2() won't fail past thesuccessful call of shmem_whiteout().Not hard to fix, fortunately - mtree_store() can't fail if the index weare trying to store into is already present in the tree as a singleton.For simple_offset_rename_exchange() that's enough - we just need to becareful about the order of operations.For simple_offset_rename() solution is to preinsert the target into thetree for new_dir; the rest can be done without any potentially failingoperations.That preinsertion has to be done in shmem_rename2() rather than insimple_offset_rename() itself - otherwise we'd need to deal with thepossibility of failure after successful shmem_whiteout().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71074 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:functionfs: fix the open/removal racesffs_epfile_open() can race with removal, ending up with file->private_datapointing to freed object.There is a total count of opened files on functionfs (both ep0 anddynamic ones) and when it hits zero, dynamic files get removed.Unfortunately, that removal can happen while another thread isin ffs_epfile_open(), but has not incremented the count yet.In that case open will succeed, leaving us with UAF on any subsequentread() or write().The root cause is that ffs->opened is misused; atomic_dec_and_test() vs.atomic_add_return() is not a good idea, when object remains visible allalong.To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we hadzero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from thecallback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed,along with checking that state is FFS_ACTIVE.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71075 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aic94xx: fix use-after-free in device removal pathThe asd_pci_remove() function fails to synchronize with pending taskletsbefore freeing the asd_ha structure, leading to a potentialuse-after-free vulnerability.When a device removal is triggered (via hot-unplug or module unload),race condition can occur.The fix adds tasklet_kill() before freeing the asd_ha structure,ensuring all scheduled tasklets complete before cleanup proceeds.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71077 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Cap the number of PCR bankstpm2_get_pcr_allocation() does not cap any upper limit for the number ofbanks. Cap the limit to eight banks so that out of bounds values comingfrom external I/O cause on only limited harm.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71095 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix the crash issue for zero copy XDP_TX actionThere is a crash issue when running zero copy XDP_TX action, the crashlog is shown below.[ 216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000[ 216.187524] Internal error: Oops: 0000000096000144 [#1] SMP[ 216.301694] Call trace:[ 216.304130] dcache_clean_poc+0x20/0x38 (P)[ 216.308308] __dma_sync_single_for_device+0x1bc/0x1e0[ 216.313351] stmmac_xdp_xmit_xdpf+0x354/0x400[ 216.317701] __stmmac_xdp_run_prog+0x164/0x368[ 216.322139] stmmac_napi_poll_rxtx+0xba8/0xf00[ 216.326576] __napi_poll+0x40/0x218[ 216.408054] Kernel panic - not syncing: Oops: Fatal exception in interruptFor XDP_TX action, the xdp_buff is converted to xdp_frame byxdp_convert_buff_to_frame(). The memory type of the resulting xdp_framedepends on the memory type of the xdp_buff. For page pool based xdp_buffit produces xdp_frame with memory type MEM_TYPE_PAGE_POOL. For zero copyXSK pool based xdp_buff it produces xdp_frame with memory typeMEM_TYPE_PAGE_ORDER0. However, stmmac_xdp_xmit_back() does not check thememory type and always uses the page pool type, this leads to invalidmappings and causes the crash. Therefore, check the xdp_buff memory typein stmmac_xdp_xmit_back() to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71098 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ip6_gre: make ip6gre_header() robustOver the years, syzbot found many ways to crash the kernelin ip6gre_header() [1].This involves team or bonding drivers ability to dynamicallychange their dev->needed_headroom and/or dev->hard_header_lenIn this particular crash mld_newpack() allocated an skbwith a too small reserve/headroom, and by the time mld_sendpack()was called, syzbot managed to attach an ip6gre device.[1]skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:213 ! skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 neigh_output include/net/neighbour.h:556 [inline] ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline] ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71105 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: use global inline_xattr_slab instead of per-sb slab cacheAs Hong Yun reported in mailing list:loop7: detected capacity change from 0 to 131072------------[ cut here ]------------kmem_cache of name 'f2fs_xattr_entry-7:7' already existsWARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 kmem_cache_sanity_check mm/slab_common.c:109 [inline]WARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 __kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307CPU: 0 UID: 0 PID: 24426 Comm: syz.7.1370 Not tainted 6.17.0-rc4 #1 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014RIP: 0010:kmem_cache_sanity_check mm/slab_common.c:109 [inline]RIP: 0010:__kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307Call Trace: __kmem_cache_create include/linux/slab.h:353 [inline] f2fs_kmem_cache_create fs/f2fs/f2fs.h:2943 [inline] f2fs_init_xattr_caches+0xa5/0xe0 fs/f2fs/xattr.c:843 f2fs_fill_super+0x1645/0x2620 fs/f2fs/super.c:4918 get_tree_bdev_flags+0x1fb/0x260 fs/super.c:1692 vfs_get_tree+0x43/0x140 fs/super.c:1815 do_new_mount+0x201/0x550 fs/namespace.c:3808 do_mount fs/namespace.c:4136 [inline] __do_sys_mount fs/namespace.c:4347 [inline] __se_sys_mount+0x298/0x2f0 fs/namespace.c:4324 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x8e/0x3a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe bug can be reproduced w/ below scripts:- mount /dev/vdb /mnt1- mount /dev/vdc /mnt2- umount /mnt1- mounnt /dev/vdb /mnt1The reason is if we created two slab caches, named f2fs_xattr_entry-7:3and f2fs_xattr_entry-7:7, and they have the same slab size. Actually,slab system will only create one slab cache core structure which hasslab name of "f2fs_xattr_entry-7:3", and two slab caches share the samestructure and cache address.So, if we destroy f2fs_xattr_entry-7:3 cache w/ cache address, it willdecrease reference count of slab cache, rather than release slab cacheentirely, since there is one more user has referenced the cache.Then, if we try to create slab cache w/ name "f2fs_xattr_entry-7:3" again,slab system will find that there is existed cache which has the same nameand trigger the warning.Let's changes to use global inline_xattr_slab instead of per-sb slab cachefor fixing.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71108 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: Handle incorrect num_connectors capabilityThe UCSI spec states that the num_connectors field is 7 bits, and the8th bit is reserved and should be set to zero.Some buggy FW has been known to set this bit, and it can lead to asystem not booting.Flag that the FW is not behaving correctly, and auto-fix the valueso that the system boots correctly.Found on Lenovo P1 G8 during Linux enablement program. The FW willbe fixed, but seemed worth addressing in case it hit platforms thataren't officially Linux supported.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71117 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: Remove queue freezing from several sysfs store callbacksFreezing the request queue from inside sysfs store callbacks may cause adeadlock in combination with the dm-multipath driver and thequeue_if_no_path option. Additionally, freezing the request queue slowsdown system boot on systems where sysfs attributes are set synchronously.Fix this by removing the blk_mq_freeze_queue() / blk_mq_unfreeze_queue()calls from the store callbacks that do not strictly need these callbacks.Add the __data_racy annotation to request_queue.rq_timeout to suppressKCSAN data race reports about the rq_timeout reads.This patch may cause a small delay in applying the new settings.For all the attributes affected by this patch, I/O will completecorrectly whether the old or the new value of the attribute is used.This patch affects the following sysfs attributes:* io_poll_delay* io_timeout* nomerges* read_ahead_kb* rq_affinityHere is an example of a deadlock triggered by running test srp/002if this patch is not applied:task:multipathdCall Trace: __schedule+0x8c1/0x1bf0 schedule+0xdd/0x270 schedule_preempt_disabled+0x1c/0x30 __mutex_lock+0xb89/0x1650 mutex_lock_nested+0x1f/0x30 dm_table_set_restrictions+0x823/0xdf0 __bind+0x166/0x590 dm_swap_table+0x2a7/0x490 do_resume+0x1b1/0x610 dev_suspend+0x55/0x1a0 ctl_ioctl+0x3a5/0x7e0 dm_ctl_ioctl+0x12/0x20 __x64_sys_ioctl+0x127/0x1a0 x64_sys_call+0xe2b/0x17d0 do_syscall_64+0x96/0x3a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 task:(udev-worker)Call Trace: __schedule+0x8c1/0x1bf0 schedule+0xdd/0x270 blk_mq_freeze_queue_wait+0xf2/0x140 blk_mq_freeze_queue_nomemsave+0x23/0x30 queue_ra_store+0x14e/0x290 queue_attr_store+0x23e/0x2c0 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3b2/0x630 vfs_write+0x4fd/0x1390 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x276/0x17d0 do_syscall_64+0x96/0x3a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71118 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Avoid walking the Namespace if start_node is NULLAlthough commit 0c9992315e73 ("ACPICA: Avoid walking the ACPI Namespaceif it is not there") fixed the situation when both start_node andacpi_gbl_root_node are NULL, the Linux kernel mainline now still crashedon Honor Magicbook 14 Pro [1].That happens due to the access to the member of parent_node inacpi_ns_get_next_node(). The NULL pointer dereference will alwayshappen, no matter whether or not the start_node is equal toACPI_ROOT_OBJECT, so move the check of start_node being NULLout of the if block.Unfortunately, all the attempts to contact Honor have failed, theyrefused to provide any technical support for Linux.The bad DSDT table's dump could be found on GitHub [2].DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025[ rjw: Subject adjustment, changelog edits ]

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71126 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: avoid deadlock on fallback while reinjectingJakub reported an MPTCP deadlock at fallback time: WARNING: possible recursive locking detected 6.18.0-rc7-virtme #1 Not tainted -------------------------------------------- mptcp_connect/20858 is trying to acquire lock: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_try_fallback+0xd8/0x280 but task is already holding lock: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&msk->fallback_lock); lock(&msk->fallback_lock); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by mptcp_connect/20858: #0: ff1100001da18290 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_sendmsg+0x114/0x1bc0 #1: ff1100001db40fd0 (k-sk_lock-AF_INET#2){+.+.}-{0:0}, at: __mptcp_retrans+0x2cb/0xaa0 #2: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0 stack backtrace: CPU: 0 UID: 0 PID: 20858 Comm: mptcp_connect Not tainted 6.18.0-rc7-virtme #1 PREEMPT(full) Hardware name: Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0x6f/0xa0 print_deadlock_bug.cold+0xc0/0xcd validate_chain+0x2ff/0x5f0 __lock_acquire+0x34c/0x740 lock_acquire.part.0+0xbc/0x260 _raw_spin_lock_bh+0x38/0x50 __mptcp_try_fallback+0xd8/0x280 mptcp_sendmsg_frag+0x16c2/0x3050 __mptcp_retrans+0x421/0xaa0 mptcp_release_cb+0x5aa/0xa70 release_sock+0xab/0x1d0 mptcp_sendmsg+0xd5b/0x1bc0 sock_write_iter+0x281/0x4d0 new_sync_write+0x3c5/0x6f0 vfs_write+0x65e/0xbb0 ksys_write+0x17e/0x200 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fa5627cbc5e Code: 4d 89 d8 e8 14 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa RSP: 002b:00007fff1fe14700 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fa5627cbc5e RDX: 0000000000001f9c RSI: 00007fff1fe16984 RDI: 0000000000000005 RBP: 00007fff1fe14710 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff1fe16920 R13: 0000000000002000 R14: 0000000000001f9c R15: 0000000000001f9cThe packet scheduler could attempt a reinjection after receiving anMP_FAIL and before the infinite map has been transmitted, causing adeadlock since MPTCP needs to do the reinjection atomically from WRTfallback.Address the issue explicitly avoiding the reinjection in the criticalscenario. Note that this is the only fallback critical section thatcould potentially send packets and hit the double-lock.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71127 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Discard Beacon frames to non-broadcast addressBeacon frames are required to be sent to the broadcast address, see IEEEStd 802.11-2020, 11.1.3.1 ("The Address 1 field of the Beacon .. frameshall be set to the broadcast address"). A unicast Beacon frame might beused as a targeted attack to get one of the associated STAs to dosomething (e.g., using CSA to move it to another channel). As such, itis better have strict filtering for this on the received side anddiscard all Beacon frames that are sent to an unexpected address.This is even more important for cases where beacon protection is used.The current implementation in mac80211 is correctly discarding unicastBeacon frames if the Protected Frame bit in the Frame Control field isset to 0. However, if that bit is set to 1, the logic used for checkingfor configured BIGTK(s) does not actually work. If the driver does nothave logic for dropping unicast Beacon frames with Protected Frame bit1, these frames would be accepted in mac80211 processing as valid Beaconframes even though they are not protected. This would allow beaconprotection to be bypassed. While the logic for checking beaconprotection could be extended to cover this corner case, a more genericcheck for discard all Beacon frames based on A1=unicast address coversthis without needing additional changes.Address all these issues by dropping received Beacon frames if they aresent to a non-broadcast address.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71129 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:LoongArch: BPF: Sign extend kfunc call argumentsThe kfunc calls are native calls so they should follow LoongArch callingconventions. Sign extend its arguments properly to avoid kernel panic.This is done by adding a new emit_abi_ext() helper. The emit_abi_ext()helper performs extension in place meaning a value already store in thetarget register (Note: this is different from the existing sign_extend()helper and thus we can't reuse it).

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71132 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smc91x: fix broken irq-context in PREEMPT_RTWhen smc91x.c is built with PREEMPT_RT, the following splat occursin FVP_RevC:[ 13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000[ 13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106][ 13.062137] preempt=0x00000000 lock=0->0 RCU=0->1 workfn=mld_ifc_work[ 13.062266] C** replaying previous printk message **[ 13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)}[ 13.062353] Hardware name: , BIOS[ 13.062382] Workqueue: mld mld_ifc_work[ 13.062469] Call trace:[ 13.062494] show_stack+0x24/0x40 (C)[ 13.062602] __dump_stack+0x28/0x48[ 13.062710] dump_stack_lvl+0x7c/0xb0[ 13.062818] dump_stack+0x18/0x34[ 13.062926] process_scheduled_works+0x294/0x450[ 13.063043] worker_thread+0x260/0x3d8[ 13.063124] kthread+0x1c4/0x228[ 13.063235] ret_from_fork+0x10/0x20This happens because smc_special_trylock() disables IRQs even on PREEMPT_RT,but smc_special_unlock() does not restore IRQs on PREEMPT_RT.The reason is that smc_special_unlock() calls spin_unlock_irqrestore(),and rcu_read_unlock_bh() in __dev_queue_xmit() cannot invokercu_read_unlock() through __local_bh_enable_ip() when current->softirq_disable_cnt becomes zero.To address this issue, replace smc_special_trylock() with spin_trylock_irqsave().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71133 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: avoid invalid read in irdma_net_eventirdma_net_event() should not dereference anything from "neigh" (alias"ptr") until it has checked that the event is NETEVENT_NEIGH_UPDATE.Other events come with different structures pointed to by "ptr" and theymay be smaller than struct neighbour.Move the read of neigh->dev under the NETEVENT_NEIGH_UPDATE case.The bug is mostly harmless, but it triggers KASAN on debug kernels: BUG: KASAN: stack-out-of-bounds in irdma_net_event+0x32e/0x3b0 [irdma] Read of size 8 at addr ffffc900075e07f0 by task kworker/27:2/542554 CPU: 27 PID: 542554 Comm: kworker/27:2 Kdump: loaded Not tainted 5.14.0-630.el9.x86_64+debug #1 Hardware name: [...] Workqueue: events rt6_probe_deferred Call Trace: dump_stack_lvl+0x60/0xb0 print_address_description.constprop.0+0x2c/0x3f0 print_report+0xb4/0x270 kasan_report+0x92/0xc0 irdma_net_event+0x32e/0x3b0 [irdma] notifier_call_chain+0x9e/0x180 atomic_notifier_call_chain+0x5c/0x110 rt6_do_redirect+0xb91/0x1080 tcp_v6_err+0xe9b/0x13e0 icmpv6_notify+0x2b2/0x630 ndisc_redirect_rcv+0x328/0x530 icmpv6_rcv+0xc16/0x1360 ip6_protocol_deliver_rcu+0xb84/0x12e0 ip6_input_finish+0x117/0x240 ip6_input+0xc4/0x370 ipv6_rcv+0x420/0x7d0 __netif_receive_skb_one_core+0x118/0x1b0 process_backlog+0xd1/0x5d0 __napi_poll.constprop.0+0xa3/0x440 net_rx_action+0x78a/0xba0 handle_softirqs+0x2d4/0x9c0 do_softirq+0xad/0xe0

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71134 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/page_alloc: change all pageblocks migrate type on coalescingWhen a page is freed it coalesces with a buddy into a higher order pagewhile possible. When the buddy page migrate type differs, it is expectedto be updated to match the one of the page being freed.However, only the first pageblock of the buddy page is updated, while therest of the pageblocks are left unchanged.That causes warnings in later expand() and other code paths (like below),since an inconsistency between migration type of the list containing thepage and the page-owned pageblocks migration types is introduced.[ 308.986589] ------------[ cut here ]------------[ 308.987227] page type is 0, passed migratetype is 1 (nr=256)[ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270[ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E)[ 308.987439] Unloaded tainted modules: hmac_s390(E):2[ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT[ 308.987657] Tainted: [E]=UNSIGNED_MODULE[ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0)[ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270)[ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3[ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88[ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300[ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008[ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0[ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2 larl %r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5 brasl %r14,0000034997378f60 #00000349976fa5fc: af000000 mc 0,0 >00000349976fa600: a7f4ff4c brc 15,00000349976fa498 00000349976fa604: b9040026 lgr %r2,%r6 00000349976fa608: c0300088317f larl %r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1 brasl %r14,00000349976b13d0 00000349976fa614: af000000 mc 0,0[ 308.987734] Call Trace:[ 308.987738] [<00000349976fa600>] expand+0x240/0x270[ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270)[ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940[ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0[ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40[ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0[ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400[ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220[ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0[ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0[ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240[ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210[ 308.987804] [<00000349976cb0---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71135 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid5: fix possible null-pointer dereferences in raid5_store_group_thread_cnt()The variable mddev->private is first assigned to conf and then checked: conf = mddev->private; if (!conf) ...If conf is NULL, then mddev->private is also NULL. In this case,null-pointer dereferences can occur when calling raid5_quiesce(): raid5_quiesce(mddev, true); raid5_quiesce(mddev, false);since mddev->private is assigned to conf again in raid5_quiesce(), and confis dereferenced in several places, for example: conf->quiesce = 0; wake_up(&conf->wait_for_quiescent);To fix this issue, the function should unlock mddev and return beforeinvoking raid5_quiesce() when conf is NULL, following the existing patternin raid5_change_consistency_policy().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71137 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: fix "UBSAN: shift-out-of-bounds error"This patch ensures that the RX ring size (rx_pending) is notset below the permitted length. This avoids UBSANshift-out-of-bounds errors when users passes small or zeroring sizes via ethtool -G.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71138 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dpu: Add missing NULL pointer check for pingpong interfaceIt is checked almost always in dpu_encoder_phys_wb_setup_ctl(), but in asingle place the check is missing.Also use convenient locals instead of phys_enc->* where available.Patchwork: https://patchwork.freedesktop.org/patch/693860/

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71142 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cpuset: fix warning when disabling remote partitionA warning was triggered as follows:WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110RIP: 0010:remote_partition_disable+0xf7/0x110RSP: 0018:ffffc90001947d88 EFLAGS: 00000206RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7f55c8cd4887Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo "0-14" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo "0-14" > A1/A2/cpuset.cpus.exclusive # echo "root" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partitionWhen CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUsremain available for the top_cpuset, forcing partitions to share CPUs withthe top_cpuset. In this scenario, disabling the remote partition triggersa warning stating that effective_xcpus is not a subset ofsubpartitions_cpus. Partitions should be invalidated in this case toinform users that the partition is now invalid(cpus are shared withtop_cpuset).To fix this issue:1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus.2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71156 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: defer interrupt enabling until NAPI registrationCurrently, interrupts are automatically enabled immediately uponrequest. This allows interrupt to fire before the associated NAPIcontext is fully initialized and cause failures like below:[ 0.946369] Call Trace:[ 0.946369] [ 0.946369] __napi_poll+0x2a/0x1e0[ 0.946369] net_rx_action+0x2f9/0x3f0[ 0.946369] handle_softirqs+0xd6/0x2c0[ 0.946369] ? handle_edge_irq+0xc1/0x1b0[ 0.946369] __irq_exit_rcu+0xc3/0xe0[ 0.946369] common_interrupt+0x81/0xa0[ 0.946369] [ 0.946369] [ 0.946369] asm_common_interrupt+0x22/0x40[ 0.946369] RIP: 0010:pv_native_safe_halt+0xb/0x10Use the `IRQF_NO_AUTOEN` flag when requesting interrupts to prevent autoenablement and explicitly enable the interrupt in NAPI initializationpath (and disable it during NAPI teardown).This ensures that interrupt lifecycle is strictly coupled withreadiness of NAPI context.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71161 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm-verity: disable recursive forward error correctionThere are two problems with the recursive correction:1. It may cause denial-of-service. In fec_read_bufs, there is a loop thathas 253 iterations. For each iteration, we may call verity_hash_for_blockrecursively. There is a limit of 4 nested recursions - that means thatthere may be at most 253^4 (4 billion) iterations. Red Hat QE teamactually created an image that pushes dm-verity to this limit - and thisimage just makes the udev-worker process get stuck in the 'D' state.2. It doesn't work. In fec_read_bufs we store data into the variable"fio->bufs", but fio bufs is shared between recursive invocations, if"verity_hash_for_block" invoked correction recursively, it wouldoverwrite partially filled fio->bufs.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71162 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: tegra-adma: Fix use-after-freeA use-after-free bug exists in the Tegra ADMA driver when audio streamsare terminated, particularly during XRUN conditions. The issue occurswhen the DMA buffer is freed by tegra_adma_terminate_all() before thevchan completion tasklet finishes accessing it.The race condition follows this sequence: 1. DMA transfer completes, triggering an interrupt that schedules the completion tasklet (tasklet has not executed yet) 2. Audio playback stops, calling tegra_adma_terminate_all() which frees the DMA buffer memory via kfree() 3. The scheduled tasklet finally executes, calling vchan_complete() which attempts to access the already-freed memorySince tasklets can execute at any time after being scheduled, there isno guarantee that the buffer will remain valid when vchan_complete()runs.Fix this by properly synchronizing the virtual channel completion: - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the descriptors as terminated instead of freeing the descriptor. - Add the callback tegra_adma_synchronize() that calls vchan_synchronize() which kills any pending tasklets and frees any terminated descriptors.Crash logs:[ 337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0[ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0[ 337.427562] Call trace:[ 337.427564] dump_backtrace+0x0/0x320[ 337.427571] show_stack+0x20/0x30[ 337.427575] dump_stack_lvl+0x68/0x84[ 337.427584] print_address_description.constprop.0+0x74/0x2b8[ 337.427590] kasan_report+0x1f4/0x210[ 337.427598] __asan_load8+0xa0/0xd0[ 337.427603] vchan_complete+0x124/0x3b0[ 337.427609] tasklet_action_common.constprop.0+0x190/0x1d0[ 337.427617] tasklet_action+0x30/0x40[ 337.427623] __do_softirq+0x1a0/0x5c4[ 337.427628] irq_exit+0x110/0x140[ 337.427633] handle_domain_irq+0xa4/0xe0[ 337.427640] gic_handle_irq+0x64/0x160[ 337.427644] call_on_irq_stack+0x20/0x4c[ 337.427649] do_interrupt_handler+0x7c/0x90[ 337.427654] el1_interrupt+0x30/0x80[ 337.427659] el1h_64_irq_handler+0x18/0x30[ 337.427663] el1h_64_irq+0x7c/0x80[ 337.427667] cpuidle_enter_state+0xe4/0x540[ 337.427674] cpuidle_enter+0x54/0x80[ 337.427679] do_idle+0x2e0/0x380[ 337.427685] cpu_startup_entry+0x2c/0x70[ 337.427690] rest_init+0x114/0x130[ 337.427695] arch_call_rest_init+0x18/0x24[ 337.427702] start_kernel+0x380/0x3b4[ 337.427706] __primary_switched+0xc0/0xc8

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71163 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: fix device leaks on compat bind and unbindMake sure to drop the reference taken when looking up the idxd device aspart of the compat bind and unbind sysfs interface.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71180 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:counter: interrupt-cnt: Drop IRQF_NO_THREAD flagAn IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, asCONFIG_PROVE_RAW_LOCK_NESTING warns:=============================[ BUG: Invalid wait context ]6.18.0-rc1+git... #1-----------------------------some-user-space-process/1251 is trying to lock:(&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter]other info that might help us debug this:context-{2:2}no locks held by some-user-space-process/....stack backtrace:CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPTCall trace: show_stack (C) dump_stack_lvl dump_stack __lock_acquire lock_acquire _raw_spin_lock_irqsave counter_push_event [counter] interrupt_cnt_isr [interrupt_cnt] __handle_irq_event_percpu handle_irq_event handle_simple_irq handle_irq_desc generic_handle_domain_irq gpio_irq_handler handle_irq_desc generic_handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler el0_interrupt __el0_irq_handler_common el0t_64_irq_handler el0t_64_irq... and Sebastian correctly points out. Remove IRQF_NO_THREAD as analternative to switching to raw_spinlock_t, because the latter would limitall potential nested locks to raw_spinlock_t only.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71184 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix NULL dereference on root when tracing inode evictionWhen evicting an inode the first thing we do is to setup tracing for it,which implies fetching the root's id. But in btrfs_evict_inode() theroot might be NULL, as implied in the next check that we do inbtrfs_evict_inode().Hence, we either should set the ->root_objectid to 0 in case the root isNULL, or we move tracing setup after checking that the root is notNULL. Setting the rootid to 0 at least gives us the possibility to tracethis call even in the case when the root is NULL, so that's the solutiontaken here.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-9615 Severity: Moderate CVSS3 score: 5.5

Description: A flaw was found in NetworkManager. The NetworkManager package allows access to files that may belong to other users. NetworkManager allows non-root users to configure the system's network. The daemon runs with root privileges and can access files owned by users different from the one who added the connection.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
NetworkManager > 0-0 (version in image is 1.52.0-160000.2.2).

CVE-2026-0990 Severity: Moderate CVSS3 score: 5.5

Description: A flaw was found in libxml2, an XML parsing library. This uncontrolled recursion vulnerability occurs in the xmlCatalogXMLResolveURI function when an XML catalog contains a delegate URI entry that references itself. A remote attacker could exploit this configuration-dependent issue by providing a specially crafted XML catalog, leading to infinite recursion and call stack exhaustion. This ultimately results in a segmentation fault, causing a Denial of Service (DoS) by crashing affected applications.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libxml2-2 > 0-0 (version in image is 2.13.8-160000.2.2).

CVE-2026-22976 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset`qfq_class->leaf_qdisc->q.qlen > 0` does not imply that the classitself is active.Two qfq_class objects may point to the same leaf_qdisc. This happenswhen:1. one QFQ qdisc is attached to the dev as the root qdisc, and2. another QFQ qdisc is temporarily referenced (e.g., via qdisc_get()/ qdisc_put()) and is pending to be destroyed, as in functiontc_new_tfilter.When packets are enqueued through the root QFQ qdisc, the sharedleaf_qdisc->q.qlen increases. At the same time, the second QFQqdisc triggers qdisc_put and qdisc_destroy: the qdisc entersqfq_reset() with its own q->q.qlen == 0, but its class's leafqdisc->q.qlen > 0. Therefore, the qfq_reset would wrongly deactivatean inactive aggregate and trigger a null-deref in qfq_deactivate_agg:[ 0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 0.903571] #PF: supervisor write access in kernel mode[ 0.903860] #PF: error_code(0x0002) - not-present page[ 0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0[ 0.904502] Oops: Oops: 0002 [#1] SMP NOPTI[ 0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE[ 0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014[ 0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2))[ 0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0Code starting with the faulting instruction=========================================== 0: 0f 84 4d 01 00 00 je 0x153 6: 48 89 70 18 mov %rsi,0x18(%rax) a: 8b 4b 10 mov 0x10(%rbx),%ecx d: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx 14: 48 8b 78 08 mov 0x8(%rax),%rdi 18: 48 d3 e2 shl %cl,%rdx 1b: 48 21 f2 and %rsi,%rdx 1e: 48 2b 13 sub (%rbx),%rdx 21: 48 8b 30 mov (%rax),%rsi 24: 48 d3 ea shr %cl,%rdx 27: 8b 4b 18 mov 0x18(%rbx),%ecx ...[ 0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246[ 0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000[ 0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000[ 0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000[ 0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880[ 0.909179] FS: 000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000[ 0.909572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0[ 0.910247] PKRU: 55555554[ 0.910391] Call Trace:[ 0.910527] [ 0.910638] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485)[ 0.910826] qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036)[ 0.911040] __qdisc_destroy (net/sched/sch_generic.c:1076)[ 0.911236] tc_new_tfilter (net/sched/cls_api.c:2447)[ 0.911447] rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)[ 0.911663] ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861)[ 0.911894] netlink_rcv_skb (net/netlink/af_netlink.c:2550)[ 0.912100] netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)[ 0.912296] ? __alloc_skb (net/core/skbuff.c:706)[ 0.912484] netlink_sendmsg (net/netlink/af---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22978 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: avoid kernel-infoleak from struct iw_pointstruct iw_point has a 32bit hole on 64bit arches.struct iw_point { void __user *pointer; /* Pointer to the data (in user space) */ __u16 length; /* number of fields or size in bytes */ __u16 flags; /* Optional params */};Make sure to zero the structure to avoid disclosing 32bits of kernel datato user space.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22979 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix memory leak in skb_segment_list for GRO packetsWhen skb_segment_list() is called during packet forwarding, it handlespackets that were aggregated by the GRO engine.Historically, the segmentation logic in skb_segment_list assumes thatindividual segments are split from a parent SKB and may need to carrytheir own socket memory accounting. Accordingly, the code transferstruesize from the parent to the newly created segments.Prior to commit ed4cccef64c1 ("gro: fix ownership transfer"), thistruesize subtraction in skb_segment_list() was valid because fragmentsstill carry a reference to the original socket.However, commit ed4cccef64c1 ("gro: fix ownership transfer") changedthis behavior by ensuring that fraglist entries are explicitlyorphaned (skb->sk = NULL) to prevent illegal orphaning later in thestack. This change meant that the entire socket memory charge remainedwith the head SKB, but the corresponding accounting logic inskb_segment_list() was never updated.As a result, the current code unconditionally adds each fragment'struesize to delta_truesize and subtracts it from the parent SKB. Sincethe fragments are no longer charged to the socket, this subtractionresults in an effective under-count of memory when the head is freed.This causes sk_wmem_alloc to remain non-zero, preventing socketdestruction and leading to a persistent memory leak.The leak can be observed via KMEMLEAK when tearing down the networkingenvironment:unreferenced object 0xffff8881e6eb9100 (size 2048): comm "ping", pid 6720, jiffies 4295492526 backtrace: kmem_cache_alloc_noprof+0x5c6/0x800 sk_prot_alloc+0x5b/0x220 sk_alloc+0x35/0xa00 inet6_create.part.0+0x303/0x10d0 __sock_create+0x248/0x640 __sys_socket+0x11b/0x1d0Since skb_segment_list() is exclusively used for SKB_GSO_FRAGLISTpackets constructed by GRO, the truesize adjustment is removed.The call to skb_release_head_state() must be preserved. As documented incommit cf673ed0e057 ("net: fix fraglist segmentation reference countleak"), it is still required to correctly drop references to SKBextensions that may be overwritten during __copy_skb_header().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22980 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: provide locking for v4_end_graceWriting to v4_end_grace can race with server shutdown and result inmemory being accessed after it was freed - reclaim_str_hashtbl inparticularly.We cannot hold nfsd_mutex across the nfsd4_end_grace() call as that isheld while client_tracking_op->init() is called and that can wait foran upcall to nfsdcltrack which can write to v4_end_grace, resulting in adeadlock.nfsd4_end_grace() is also called by the landromat work queue and thisdoesn't require locking as server shutdown will stop the work and waitfor it before freeing anything that nfsd4_end_grace() might access.However, we must be sure that writing to v4_end_grace doesn't restartthe work item after shutdown has already waited for it. For this weadd a new flag protected with nn->client_lock. It is set only while itis safe to make client tracking calls, and v4_end_grace only scheduleswork while the flag is set with the spinlock held.So this patch adds a nfsd_net field "client_tracking_active" which isset as described. Another field "grace_end_forced", is set whenv4_end_grace is written. After this is set, and providingclient_tracking_active is set, the laundromat is scheduled.This "grace_end_forced" field bypasses other checks for whether thegrace period has finished.This resolves a race which can result in use-after-free.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22981 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: detach and close netdevs while handling a resetProtect the reset path from callbacks by setting the netdevs to detachedstate and close any netdevs in UP state until the reset handling hascompleted. During a reset, the driver will de-allocate resources for thevport, and there is no guarantee that those will recover, which is why theexisting vport_ctrl_lock does not provide sufficient protection.idpf_detach_and_close() is called right before reset handling. If thereset handling succeeds, the netdevs state is recovered via call toidpf_attach_and_open(). If the reset handling fails the netdevs remaindown. The detach/down calls are protected with RTNL lock to avoid racingwith callbacks. On the recovery side the attach can be done withoutholding the RTNL lock as there are no callbacks expected at that point,due to detach/close always being done first in that flow.The previous logic restoring the netdevs state based on theIDPF_VPORT_UP_REQUESTED flag in the init task is not needed anymore, hencethe removal of idpf_set_vport_state(). The IDPF_VPORT_UP_REQUESTED isstill being used to restore the state of the netdevs following the reset,but has no use outside of the reset handling flow.idpf_init_hard_reset() is converted to void, since it was used as such andthere is no error handling being done based on its return value.Before this change, invoking hard and soft resets simultaneously willcause the driver to lose the vport state:ip -br a UPecho 1 > /sys/class/net/ens801f0/device/reset& \ethtool -L ens801f0 combined 8ip -br a DOWNip link set upip -br a DOWNAlso in case of a failure in the reset path, the netdev is leftexposed to external callbacks, while vport resources are notinitialized, leading to a crash on subsequent ifup/down:[408471.398966] idpf 0000:83:00.0: HW reset detected[408471.411744] idpf 0000:83:00.0: Device HW Reset initiated[408472.277901] idpf 0000:83:00.0: The driver was unable to contact the device's firmware. Check that the FW is running. Driver state= 0x2[408508.125551] BUG: kernel NULL pointer dereference, address: 0000000000000078[408508.126112] #PF: supervisor read access in kernel mode[408508.126687] #PF: error_code(0x0000) - not-present page[408508.127256] PGD 2aae2f067 P4D 0[408508.127824] Oops: Oops: 0000 [#1] SMP NOPTI...[408508.130871] RIP: 0010:idpf_stop+0x39/0x70 [idpf]...[408508.139193] Call Trace:[408508.139637] [408508.140077] __dev_close_many+0xbb/0x260[408508.140533] __dev_change_flags+0x1cf/0x280[408508.140987] netif_change_flags+0x26/0x70[408508.141434] dev_change_flags+0x3d/0xb0[408508.141878] devinet_ioctl+0x460/0x890[408508.142321] inet_ioctl+0x18e/0x1d0[408508.142762] ? _copy_to_user+0x22/0x70[408508.143207] sock_do_ioctl+0x3d/0xe0[408508.143652] sock_ioctl+0x10e/0x330[408508.144091] ? find_held_lock+0x2b/0x80[408508.144537] __x64_sys_ioctl+0x96/0xe0[408508.144979] do_syscall_64+0x79/0x3d0[408508.145415] entry_SYSCALL_64_after_hwframe+0x76/0x7e[408508.145860] RIP: 0033:0x7f3e0bb4caff

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mscc: ocelot: Fix crash when adding interface under a lagCommit 15faa1f67ab4 ("lan966x: Fix crash when adding interface under a lag")fixed a similar issue in the lan966x driver caused by a NULL pointer dereference.The ocelot_set_aggr_pgids() function in the ocelot driver has similar logicand is susceptible to the same crash.This issue specifically affects the ocelot_vsc7514.c frontend, which leavesunused ports as NULL pointers. The felix_vsc9959.c frontend is unaffected asit uses the DSA framework which registers all ports.Fix this by checking if the port pointer is valid before accessing it.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22984 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: prevent potential out-of-bounds reads in handle_auth_done()Perform an explicit bounds check on payload_len to avoid a possibleout-of-bounds access in the callout.[ idryomov: changelog ]

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22985 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: Fix RSS LUT NULL pointer crash on early ethtool operationsThe RSS LUT is not initialized until the interface comes up, causingthe following NULL pointer crash when ethtool operations like rxhash on/offare performed before the interface is brought up for the first time.Move RSS LUT initialization from ndo_open to vport creation to ensure LUTis always available. This enables RSS configuration via ethtool beforebringing the interface up. Simplify LUT management by maintaining allchanges in the driver's soft copy and programming zeros to the indirectiontable when rxhash is disabled. Defer HW programming until the interfacecomes up if it is down during rxhash and LUT configuration changes.Steps to reproduce:** Load idpf driver; interfaces will be created modprobe idpf** Before bringing the interfaces up, turn rxhash off ethtool -K eth2 rxhash off[89408.371875] BUG: kernel NULL pointer dereference, address: 0000000000000000[89408.371908] #PF: supervisor read access in kernel mode[89408.371924] #PF: error_code(0x0000) - not-present page[89408.371940] PGD 0 P4D 0[89408.371953] Oops: Oops: 0000 [#1] SMP NOPTI[89408.372052] RIP: 0010:memcpy_orig+0x16/0x130[89408.372310] Call Trace:[89408.372317] [89408.372326] ? idpf_set_features+0xfc/0x180 [idpf][89408.372363] __netdev_update_features+0x295/0xde0[89408.372384] ethnl_set_features+0x15e/0x460[89408.372406] genl_family_rcv_msg_doit+0x11f/0x180[89408.372429] genl_rcv_msg+0x1ad/0x2b0[89408.372446] ? __pfx_ethnl_set_features+0x10/0x10[89408.372465] ? __pfx_genl_rcv_msg+0x10/0x10[89408.372482] netlink_rcv_skb+0x58/0x100[89408.372502] genl_rcv+0x2c/0x50[89408.372516] netlink_unicast+0x289/0x3e0[89408.372533] netlink_sendmsg+0x215/0x440[89408.372551] __sys_sendto+0x234/0x240[89408.372571] __x64_sys_sendto+0x28/0x30[89408.372585] x64_sys_call+0x1909/0x1da0[89408.372604] do_syscall_64+0x7a/0xfa0[89408.373140] ? clear_bhb_loop+0x60/0xb0[89408.373647] entry_SYSCALL_64_after_hwframe+0x76/0x7e[89408.378887]

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22989 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: check that server is running in unlock_filesystemIf we are trying to unlock the filesystem via an administrativeinterface and nfsd isn't running, it crashes the server. Thishappens currently because nfsd4_revoke_states() access statestructures (eg., conf_id_hashtbl) that has been freed as a partof the server shutdown.[ 59.465072] Call trace:[ 59.465308] nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P)[ 59.465830] write_unlock_fs+0x258/0x440 [nfsd][ 59.466278] nfsctl_transaction_write+0xb0/0x120 [nfsd][ 59.466780] vfs_write+0x1f0/0x938[ 59.467088] ksys_write+0xfc/0x1f8[ 59.467395] __arm64_sys_write+0x74/0xb8[ 59.467746] invoke_syscall.constprop.0+0xdc/0x1e8[ 59.468177] do_el0_svc+0x154/0x1d8[ 59.468489] el0_svc+0x40/0xe0[ 59.468767] el0t_64_sync_handler+0xa0/0xe8[ 59.469138] el0t_64_sync+0x1ac/0x1b0Ensure this can't happen by taking the nfsd_mutex and checking thatthe server is still up, and then holding the mutex across the call tonfsd4_revoke_states().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22991 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make free_choose_arg_map() resilient to partial allocationfree_choose_arg_map() may dereference a NULL pointer if its caller failsafter a partial allocation.For example, in decode_choose_args(), if allocation of arg_map->argsfails, execution jumps to the fail label and free_choose_arg_map() iscalled. Since arg_map->size is updated to a non-zero value before memoryallocation, free_choose_arg_map() will iterate over arg_map->args anddereference a NULL pointer.To prevent this potential NULL pointer dereference and makefree_choose_arg_map() more resilient, add checks for pointers beforeiterating.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22992 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: return the handler error from mon_handle_auth_done()Currently any error from ceph_auth_handle_reply_done() is propagatedvia finish_auth() but isn't returned from mon_handle_auth_done(). Thisresults in higher layers learning that (despite the monitor consideringus to be successfully authenticated) something went wrong in theauthentication phase and reacting accordingly, but msgr2 still tryingto proceed with establishing the session in the background. In thecase of secure mode this can trigger a WARN in setup_crypto() and laterlead to a NULL pointer dereference inside of prepare_auth_signature().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22993 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: Fix RSS LUT NULL ptr issue after soft resetDuring soft reset, the RSS LUT is freed and not restored unless theinterface is up. If an ethtool command that accesses the rss lut isattempted immediately after reset, it will result in NULL ptrdereference. Also, there is no need to reset the rss lut if the soft resetdoes not involve queue count change.After soft reset, set the RSS LUT to default values based on the updatedqueue count only if the reset was a result of a queue count change andthe LUT was not configured by the user. In all other cases, don't touchthe LUT.Steps to reproduce:** Bring the interface down (if up)ifconfig eth1 down** update the queue count (eg., 27->20)ethtool -L eth1 combined 20** display the RSS LUTethtool -x eth1[82375.558338] BUG: kernel NULL pointer dereference, address: 0000000000000000[82375.558373] #PF: supervisor read access in kernel mode[82375.558391] #PF: error_code(0x0000) - not-present page[82375.558408] PGD 0 P4D 0[82375.558421] Oops: Oops: 0000 [#1] SMP NOPTI[82375.558516] RIP: 0010:idpf_get_rxfh+0x108/0x150 [idpf][82375.558786] Call Trace:[82375.558793] [82375.558804] rss_prepare.isra.0+0x187/0x2a0[82375.558827] rss_prepare_data+0x3a/0x50[82375.558845] ethnl_default_doit+0x13d/0x3e0[82375.558863] genl_family_rcv_msg_doit+0x11f/0x180[82375.558886] genl_rcv_msg+0x1ad/0x2b0[82375.558902] ? __pfx_ethnl_default_doit+0x10/0x10[82375.558920] ? __pfx_genl_rcv_msg+0x10/0x10[82375.558937] netlink_rcv_skb+0x58/0x100[82375.558957] genl_rcv+0x2c/0x50[82375.558971] netlink_unicast+0x289/0x3e0[82375.558988] netlink_sendmsg+0x215/0x440[82375.559005] __sys_sendto+0x234/0x240[82375.559555] __x64_sys_sendto+0x28/0x30[82375.560068] x64_sys_call+0x1909/0x1da0[82375.560576] do_syscall_64+0x7a/0xfa0[82375.561076] ? clear_bhb_loop+0x60/0xb0[82375.561567] entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22994 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix reference count leak in bpf_prog_test_run_xdp()syzbot is reporting unregister_netdevice: waiting for sit0 to become free. Usage count = 2problem. A debug printk() patch found that a refcount is obtained atxdp_convert_md_to_buff() from bpf_prog_test_run_xdp().According to commit ec94670fcb3b ("bpf: Support specifying ingress viaxdp_md context in BPF_PROG_TEST_RUN"), the refcount obtained byxdp_convert_md_to_buff() will be released by xdp_convert_buff_to_md().Therefore, we can consider that the error handling path introduced bycommit 1c1949982524 ("bpf: introduce frags support tobpf_prog_test_run_xdp()") forgot to call xdp_convert_buff_to_md().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22996 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Don't store mlx5e_priv in mlx5e_dev devlink privmlx5e_priv is an unstable structure that can be memset(0) if profileattaching fails, mlx5e_priv in mlx5e_dev devlink private is used toreference the netdev and mdev associated with that struct. Instead,store netdev directly into mlx5e_dev and get mdev from the containingmlx5_adev aux device structure.This fixes a kernel oops in mlx5e_remove when switchdev mode fails dueto change profile failure.$ devlink dev eswitch set pci/0000:00:03.0 mode switchdevError: mlx5_core: Failed setting eswitch to offloads.dmesg:workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12$ devlink dev reload pci/0000:00:03.0 ==> oopsBUG: kernel NULL pointer dereference, address: 0000000000000520 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present pagePGD 0 P4D 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014RIP: 0010:mlx5e_remove+0x68/0x130RSP: 0018:ffffc900034838f0 EFLAGS: 00010246RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0Call Trace: device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22997 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rtsSince j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() iscalled only when the timer is enabled, we need to callj1939_session_deactivate_activate_next() if we cancelled the timer.Otherwise, refcount for j1939_session leaks, which will later appear as| unregister_netdevice: waiting for vcan0 to become free. Usage count = 2.problem.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22998 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovecCommit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length")added ttag bounds checking and data_offsetvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validatewhether the command's data structures (cmd->req.sg and cmd->iov) havebeen properly initialized before processing H2C_DATA PDUs.The nvmet_tcp_build_pdu_iovec() function dereferences these pointerswithout NULL checks. This can be triggered by sending H2C_DATA PDUimmediately after the ICREQ/ICRESP handshake, beforesending a CONNECT command or NVMe write command.Attack vectors that trigger NULL pointer dereferences:1. H2C_DATA PDU sent before CONNECT -> both pointers NULL2. H2C_DATA PDU for READ command -> cmd->req.sg allocated, cmd->iov NULL3. H2C_DATA PDU for uninitialized command slot -> both pointers NULLThe fix validates both cmd->req.sg and cmd->iov before callingnvmet_tcp_build_pdu_iovec(). Both checks are required because:- Uninitialized commands: both NULL- READ commands: cmd->req.sg allocated, cmd->iov NULL- WRITE commands: both allocated

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23000 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix crash on profile change rollback failuremlx5e_netdev_change_profile can fail to attach a new profile and canfail to rollback to old profile, in such case, we could end up with adangling netdev with a fully reset netdev_priv. A retry to changeprofile, e.g. another attempt to call mlx5e_netdev_change_profile viaswitchdev mode change, will crash trying to access the now NULLpriv->mdev.This fix allows mlx5e_netdev_change_profile() to handle previousfailures and an empty priv, by not assuming priv is valid.Pass netdev and mdev to all flows requiringmlx5e_netdev_change_profile() and avoid passing priv.In mlx5e_netdev_change_profile() check if current priv is valid, and ifnot, just attach the new profile without trying to access the old one.This fixes the following oops, when enabling switchdev mode for the 2ndtime after first time failure: ## Enabling switchdev mode first time:mlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offloadworkqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 ^^^^^^^^mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) ## retry: Enabling switchdev mode 2nd time:mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offloadBUG: kernel NULL pointer dereference, address: 0000000000000038 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present pagePGD 0 P4D 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014RIP: 0010:mlx5e_detach_netdev+0x3c/0x90Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07RSP: 0018:ffffc90000673890 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0Call Trace: mlx5e_netdev_change_profile+0x45/0xb0 mlx5e_vport_rep_load+0x27b/0x2d0 mlx5_esw_offloads_rep_load+0x72/0xf0 esw_offloads_enable+0x5d0/0x970 mlx5_eswitch_enable_locked+0x349/0x430 ? is_mp_supported+0x57/0xb0 mlx5_devlink_eswitch_mode_set+0x26b/0x430 devlink_nl_eswitch_set_doit+0x6f/0xf0 genl_family_rcv_msg_doit+0xe8/0x140 genl_rcv_msg+0x18b/0x290 ? __pfx_devlink_nl_pre_doit+0x10/0x10 ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10 ? __pfx_devlink_nl_post_doit+0x10/0x10 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x52/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x282/0x3e0 ? __alloc_skb+0xd6/0x190 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x213/0x220 ? __sys_recvmsg+0x6a/0xd0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7fdfb8495047

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:lib/buildid: use __kernel_read() for sleepable contextPrevent a "BUG: unable to handle kernel NULL pointer dereference infilemap_read_folio".For the sleepable context, convert freader to use __kernel_read() insteadof direct page cache access via read_cache_folio(). This simplifies thefaultable code path by using the standard kernel file reading interfacewhich handles all the complexity of reading file data.At the moment we are not changing the code for non-sleepable context whichuses filemap_get_folio() and only succeeds if the target folios arealready in memory and up-to-date. The reason is to keep the patch simpleand easier to backport to stable kernels.Syzbot repro does not crash the kernel anymore and the selftests runsuccessfully.In the follow up we will make __kernel_read() with IOCB_NOWAIT work fornon-sleepable contexts. In addition, I would like to replace thesecretmem check with a more generic approach and will add fstest for thebuildid code.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23006 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: tlv320adcx140: fix null pointerThe "snd_soc_component" in "adcx140_priv" was only used once but neverset. It was only used for reaching "dev" which is already present in"adcx140_priv".

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23007 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: zero non-PI portion of auto integrity bufferThe auto-generated integrity buffer for writes needs to be fullyinitialized before being passed to the underlying block device,otherwise the uninitialized memory can be read back by userspace oranyone with physical access to the storage device. If protectioninformation is generated, that portion of the integrity buffer isalready initialized. The integrity data is also zeroed if PI generationis disabled via sysfs or the PI tuple size is 0. However, this missesthe case where PI is generated and the PI tuple size is nonzero, but themetadata size is larger than the PI tuple. In this case, the remainder("opaque") of the metadata is left uninitialized.Generalize the BLK_INTEGRITY_CSUM_NONE check to cover any case when themetadata is larger than just the PI tuple.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23011 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: ip_gre: make ipgre_header() robustAnalog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust")Over the years, syzbot found many ways to crash the kernelin ipgre_header() [1].This involves team or bonding drivers ability to dynamicallychange their dev->needed_headroom and/or dev->hard_header_lenIn this particular crash mld_newpack() allocated an skbwith a too small reserve/headroom, and by the time mld_sendpack()was called, syzbot managed to attach an ipgre device.[1]skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 !Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213Call Trace: skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: octeon_ep_vf: fix free_irq dev_id mismatch in IRQ rollbackoctep_vf_request_irqs() requests MSI-X queue IRQs with dev_id set toioq_vector. If request_irq() fails part-way, the rollback loop callsfree_irq() with dev_id set to 'oct', which does not match the originaldev_id and may leave the irqaction registered.This can keep IRQ handlers alive while ioq_vector is later freed duringunwind/teardown, leading to a use-after-free or crash when an interruptfires.Fix the error path to free IRQs with the same ioq_vector dev_id usedduring request_irq().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23017 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix error handling in the init_task on loadIf the init_task fails during a driver load, we end up without vports andnetdevs, effectively failing the entire process. In that state asubsequent reset will result in a crash as the service task attempts toaccess uninitialized resources. Following trace is from an error in theinit_task where the CREATE_VPORT (op 501) is rejected by the FW:[40922.763136] idpf 0000:83:00.0: Device HW Reset initiated[40924.449797] idpf 0000:83:00.0: Transaction failed (op 501)[40958.148190] idpf 0000:83:00.0: HW reset detected[40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8...[40958.168094] Workqueue: idpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf][40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf]...[40958.177932] Call Trace:[40958.178491] [40958.179040] process_one_work+0x226/0x6d0[40958.179609] worker_thread+0x19e/0x340[40958.180158] ? __pfx_worker_thread+0x10/0x10[40958.180702] kthread+0x10f/0x250[40958.181238] ? __pfx_kthread+0x10/0x10[40958.181774] ret_from_fork+0x251/0x2b0[40958.182307] ? __pfx_kthread+0x10/0x10[40958.182834] ret_from_fork_asm+0x1a/0x30[40958.183370] Fix the error handling in the init_task to make sure the service andmailbox tasks are disabled if the error happens during load. These arestarted in idpf_vc_core_init(), which spawns the init_task and has no wayof knowing if it failed. If the error happens on reset, followingsuccessful driver load, the tasks can still run, as that will allow thenetdevs to attempt recovery through another reset. Stop the PTP callbackseither way as those will be restarted by the call to idpf_vc_core_init()during a successful reset.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23020 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: 3com: 3c59x: fix possible null dereference in vortex_probe1()pdev can be null and free_ring: can be called in 1297 with a nullpdev.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23035 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of privmlx5e_priv is an unstable structure that can be memset(0) if profileattaching fails.Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on avalid netdev.On mlx5e_remove: Check validity of priv->profile, before attemptingto cleanup any resources that might be not there.This fixes a kernel oops in mlx5e_remove when switchdev mode fails dueto change profile failure.$ devlink dev eswitch set pci/0000:00:03.0 mode switchdevError: mlx5_core: Failed setting eswitch to offloads.dmesg:workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTRmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12$ devlink dev reload pci/0000:00:03.0 ==> oopsBUG: kernel NULL pointer dereference, address: 0000000000000370PGD 0 P4D 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400FS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0Call Trace: mlx5e_remove+0x57/0x110 device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23046 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virtio_net: fix device mismatch in devm_kzalloc/devm_kfreeInitial rss_hdr allocation uses virtio_device->device,but virtnet_set_queues() frees using net_device->device.This device mismatch causing below devres warning[ 3788.514041] ------------[ cut here ]------------[ 3788.514044] WARNING: drivers/base/devres.c:1095 at devm_kfree+0x84/0x98, CPU#16: vdpa/1463[ 3788.514054] Modules linked in: octep_vdpa virtio_net virtio_vdpa [last unloaded: virtio_vdpa][ 3788.514064] CPU: 16 UID: 0 PID: 1463 Comm: vdpa Tainted: G W 6.18.0 #10 PREEMPT[ 3788.514067] Tainted: [W]=WARN[ 3788.514069] Hardware name: Marvell CN106XX board (DT)[ 3788.514071] pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)[ 3788.514074] pc : devm_kfree+0x84/0x98[ 3788.514076] lr : devm_kfree+0x54/0x98[ 3788.514079] sp : ffff800084e2f220[ 3788.514080] x29: ffff800084e2f220 x28: ffff0003b2366000 x27: 000000000000003f[ 3788.514085] x26: 000000000000003f x25: ffff000106f17c10 x24: 0000000000000080[ 3788.514089] x23: ffff00045bb8ab08 x22: ffff00045bb8a000 x21: 0000000000000018[ 3788.514093] x20: ffff0004355c3080 x19: ffff00045bb8aa00 x18: 0000000000080000[ 3788.514098] x17: 0000000000000040 x16: 000000000000001f x15: 000000000007ffff[ 3788.514102] x14: 0000000000000488 x13: 0000000000000005 x12: 00000000000fffff[ 3788.514106] x11: ffffffffffffffff x10: 0000000000000005 x9 : ffff800080c8c05c[ 3788.514110] x8 : ffff800084e2eeb8 x7 : 0000000000000000 x6 : 000000000000003f[ 3788.514115] x5 : ffff8000831bafe0 x4 : ffff800080c8b010 x3 : ffff0004355c3080[ 3788.514119] x2 : ffff0004355c3080 x1 : 0000000000000000 x0 : 0000000000000000[ 3788.514123] Call trace:[ 3788.514125] devm_kfree+0x84/0x98 (P)[ 3788.514129] virtnet_set_queues+0x134/0x2e8 [virtio_net][ 3788.514135] virtnet_probe+0x9c0/0xe00 [virtio_net][ 3788.514139] virtio_dev_probe+0x1e0/0x338[ 3788.514144] really_probe+0xc8/0x3a0[ 3788.514149] __driver_probe_device+0x84/0x170[ 3788.514152] driver_probe_device+0x44/0x120[ 3788.514155] __device_attach_driver+0xc4/0x168[ 3788.514158] bus_for_each_drv+0x8c/0xf0[ 3788.514161] __device_attach+0xa4/0x1c0[ 3788.514164] device_initial_probe+0x1c/0x30[ 3788.514168] bus_probe_device+0xb4/0xc0[ 3788.514170] device_add+0x614/0x828[ 3788.514173] register_virtio_device+0x214/0x258[ 3788.514175] virtio_vdpa_probe+0xa0/0x110 [virtio_vdpa][ 3788.514179] vdpa_dev_probe+0xa8/0xd8[ 3788.514183] really_probe+0xc8/0x3a0[ 3788.514186] __driver_probe_device+0x84/0x170[ 3788.514189] driver_probe_device+0x44/0x120[ 3788.514192] __device_attach_driver+0xc4/0x168[ 3788.514195] bus_for_each_drv+0x8c/0xf0[ 3788.514197] __device_attach+0xa4/0x1c0[ 3788.514200] device_initial_probe+0x1c/0x30[ 3788.514203] bus_probe_device+0xb4/0xc0[ 3788.514206] device_add+0x614/0x828[ 3788.514209] _vdpa_register_device+0x58/0x88[ 3788.514211] octep_vdpa_dev_add+0x104/0x228 [octep_vdpa][ 3788.514215] vdpa_nl_cmd_dev_add_set_doit+0x2d0/0x3c0[ 3788.514218] genl_family_rcv_msg_doit+0xe4/0x158[ 3788.514222] genl_rcv_msg+0x218/0x298[ 3788.514225] netlink_rcv_skb+0x64/0x138[ 3788.514229] genl_rcv+0x40/0x60[ 3788.514233] netlink_unicast+0x32c/0x3b0[ 3788.514237] netlink_sendmsg+0x170/0x3b8[ 3788.514241] __sys_sendto+0x12c/0x1c0[ 3788.514246] __arm64_sys_sendto+0x30/0x48[ 3788.514249] invoke_syscall.constprop.0+0x58/0xf8[ 3788.514255] do_el0_svc+0x48/0xd0[ 3788.514259] el0_svc+0x48/0x210[ 3788.514264] el0t_64_sync_handler+0xa0/0xe8[ 3788.514268] el0t_64_sync+0x198/0x1a0[ 3788.514271] ---[ end trace 0000000000000000 ]---Fix by using virtio_device->device consistently forallocation and deallocation

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23047 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make calc_target() set t->paused, not just clear itCurrently calc_target() clears t->paused if the request shouldn't bepaused anymore, but doesn't ever set t->paused even though it's able todetermine when the request should be paused. Setting t->paused is leftto __submit_request() which is fine for regular requests but doesn'twork for linger requests -- since __submit_request() doesn't operateon linger requests, there is nowhere for lreq->t.paused to be set.One consequence of this is that watches don't get reestablished onpaused -> unpaused transitions in cases where requests have been pausedlong enough for the (paused) unwatch request to time out and for thesubsequent (re)watch request to enter the paused state. On top of thewatch not getting reestablished, rbd_reregister_watch() gets stuck withrbd_dev->watch_mutex held: rbd_register_watch __rbd_register_watch ceph_osdc_watch linger_reg_commit_waitIt's waiting for lreq->reg_commit_wait to be completed, but for that tohappen the respective request needs to end up on need_resend_linger listand be kicked when requests are unpaused. There is no chance for thatif the request in question is never marked paused in the first place.The fact that rbd_dev->watch_mutex remains taken out forever thenprevents the image from getting unmapped -- "rbd unmap" would inevitablyhang in D state on an attempt to grab the mutex.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23065 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86/amd: Fix memory leak in wbrf_record()The tmp buffer is allocated using kcalloc() but is not freed ifacpi_evaluate_dsm() fails. This causes a memory leak in the error path.Fix this by explicitly freeing the tmp buffer in the error handlingpath of acpi_evaluate_dsm().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23072 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: Fix memleak in l2tp_udp_encap_recv().syzbot reported memleak of struct l2tp_session, l2tp_tunnel,sock, etc. [0]The cited commit moved down the validation of the protocolversion in l2tp_udp_encap_recv().The new place requires an extra error handling to avoid thememleak.Let's call l2tp_session_put() there.[0]:BUG: memory leakunreferenced object 0xffff88810a290200 (size 512): comm "syz.0.17", pid 6086, jiffies 4294944299 hex dump (first 32 bytes): 7d eb 04 0c 00 00 00 00 01 00 00 00 00 00 00 00 }............... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc babb6a4f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] __do_kmalloc_node mm/slub.c:5656 [inline] __kmalloc_noprof+0x3e0/0x660 mm/slub.c:5669 kmalloc_noprof include/linux/slab.h:961 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] l2tp_session_create+0x3a/0x3b0 net/l2tp/l2tp_core.c:1778 pppol2tp_connect+0x48b/0x920 net/l2tp/l2tp_ppp.c:755 __sys_connect_file+0x7a/0xb0 net/socket.c:2089 __sys_connect+0xde/0x110 net/socket.c:2108 __do_sys_connect net/socket.c:2114 [inline] __se_sys_connect net/socket.c:2111 [inline] __x64_sys_connect+0x1c/0x30 net/socket.c:2111 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23075 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In esd_usb_open(), the URBs for USB-in transfers are allocated, added tothe dev->rx_submitted anchor and submitted. In the complete callbackesd_usb_read_bulk_callback(), the URBs are processed and resubmitted. Inesd_usb_close() the URBs are freed by callingusb_kill_anchored_urbs(&dev->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in esd_usb_close().Fix the memory leak by anchoring the URB in theesd_usb_read_bulk_callback() to the dev->rx_submitted anchor.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23085 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3-its: Avoid truncating memory addressesOn 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmemallocations to be backed by addresses physical memory above the 32-bitaddress limit, as found while experimenting with larger VMSPLITconfigurations.This caused the qemu virt model to crash in the GICv3 driver, whichallocates the 'itt' object using GFP_KERNEL. Since all memory belowthe 4GB physical address limit is in ZONE_DMA in this configuration,kmalloc() defaults to higher addresses for ZONE_NORMAL, and theITS driver stores the physical address in a 32-bit 'unsigned long'variable.Change the itt_addr variable to the correct phys_addr_t type instead,along with all other variables in this driver that hold a physicaladdress.The gicv5 driver correctly uses u64 variables, while all other irqchipdrivers don't call virt_to_phys or similar interfaces. It's expected thatother device drivers have similar issues, but fixing this one issufficient for booting a virtio based guest.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23087 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()Memory allocated for struct vscsiblk_info in scsiback_probe() is notfreed in scsiback_remove() leading to potential memory leaks on remove,as well as in the scsiback_probe() error paths. Fix that by freeing itin scsiback_remove().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:slimbus: core: fix device reference leak on report presentSlimbus devices can be allocated dynamically upon reception ofreport-present messages.Make sure to drop the reference taken when looking up already registereddevices.Note that this requires taking an extra reference in case the device hasnot yet been registered and has to be allocated.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23102 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64/fpsimd: signal: Fix restoration of SVE contextWhen SME is supported, Restoring SVE signal context can go wrong in afew ways, including placing the task into an invalid state where thekernel may read from out-of-bounds memory (and may potentially take afatal fault) and/or may kill the task with a SIGKILL.(1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL. This can only occur in unusual (but legitimate) cases where the SVE signal context has either been modified by userspace or was saved in the context of another task (e.g. as with CRIU), as otherwise the presence of an SVE signal context with SVE_SIG_FLAG_SM implies that TIF_SME is already set. While in this state, task_fpsimd_load() will NOT configure SMCR_ELx (leaving some arbitrary value configured in hardware) before restoring SVCR and attempting to restore the streaming mode SVE registers from memory via sve_load_state(). As the value of SMCR_ELx.LEN may be larger than the task's streaming SVE vector length, this may read memory outside of the task's allocated sve_state, reading unrelated data and/or triggering a fault. While this can result in secrets being loaded into streaming SVE registers, these values are never exposed. As TIF_SME is clear, fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0 accesses to streaming mode SVE registers, so these cannot be accessed directly at EL0. As fpsimd_save_user_state() verifies the live vector length before saving (S)SVE state to memory, no secret values can be saved back to memory (and hence cannot be observed via ptrace, signals, etc). When the live vector length doesn't match the expected vector length for the task, fpsimd_save_user_state() will send a fatal SIGKILL signal to the task. Hence the task may be killed after executing userspace for some period of time.(2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV. This can only occur in unusual (but legitimate) cases where ptrace has been used to set SVCR.SM after entry to the sigreturn syscall, as syscall entry clears SVCR.SM. In these cases, the the provided SVE register data will be loaded into the task's sve_state using the non-streaming SVE vector length and the FPSIMD registers will be merged into this using the streaming SVE vector length.Fix (1) by setting TIF_SME when setting SVCR.SM. This also requiresensuring that the task's sme_state has been allocated, but as this couldcontain live ZA state, it should not be zeroed. Fix (2) by clearingSVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.For consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME,and fp_type earlier, immediately after the allocation ofsve_state/sme_state, before the restore of the actual register state.This makes it easier to ensure that these are always modifiedconsistently, even if a fault is taken while reading the register datafrom the signal context. I do not expect any software to depend on theexact state restored when a fault is taken while reading the context.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23103 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: Make the addrs_lock be per portMake the addrs_lock be per port, not per ipvlan dev.Initial code seems to be written in the assumption,that any address change must occur under RTNL.But it is not so for the case of IPv6. So1) Introduce per-port addrs_lock.2) It was needed to fix places where it was forgottento take lock (ipvlan_open/ipvlan_close)This appears to be a very minor problem though.Since it's highly unlikely that ipvlan_add_addr() willbe called on 2 CPU simultaneously. But nevertheless,this could cause:1) False-negative of ipvlan_addr_busy(): one interfaceiterated through all port->ipvlans + ipvlan->addrsunder some ipvlan spinlock, and another added IPunder its own lock. Though this is only possiblefor IPv6, since looks like only ipvlan_addr6_event() can becalled without rtnl_lock.2) Race since ipvlan_ht_addr_add(port) is called underdifferent ipvlan->addrs_lock locksThis should not affect performance, since add/remove IPis a rare situation and spinlock is not taken on fastpaths.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23107 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64/fpsimd: signal: Allocate SSVE storage when restoring ZAThe code to restore a ZA context doesn't attempt to allocate the task'ssve_state before setting TIF_SME. Consequently, restoring a ZA contextcan place a task into an invalid state where TIF_SME is set but thetask's sve_state is NULL.In legitimate but uncommon cases where the ZA signal context was NOTcreated by the kernel in the context of the same task (e.g. if the taskis saved/restored with something like CRIU), we have no guarantee thatsve_state had been allocated previously. In these cases, userspace canenter streaming mode without trapping while sve_state is NULL, causing alater NULL pointer dereference when the kernel attempts to store theregister state:| # ./sigreturn-za| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000| Mem abort info:| ESR = 0x0000000096000046| EC = 0x25: DABT (current EL), IL = 32 bits| SET = 0, FnV = 0| EA = 0, S1PTW = 0| FSC = 0x06: level 2 translation fault| Data abort info:| ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000| CM = 0, WnR = 1, TnD = 0, TagAccess = 0| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0| user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00| [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000| Internal error: Oops: 0000000096000046 [#1] SMP| Modules linked in:| CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT| Hardware name: linux,dummy-virt (DT)| pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)| pc : sve_save_state+0x4/0xf0| lr : fpsimd_save_user_state+0xb0/0x1c0| sp : ffff80008070bcc0| x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658| x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000| x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40| x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000| x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c| x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020| x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0| x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48| x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000| x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440| Call trace:| sve_save_state+0x4/0xf0 (P)| fpsimd_thread_switch+0x48/0x198| __switch_to+0x20/0x1c0| __schedule+0x36c/0xce0| schedule+0x34/0x11c| exit_to_user_mode_loop+0x124/0x188| el0_interrupt+0xc8/0xd8| __el0_irq_handler_common+0x18/0x24| el0t_64_irq_handler+0x10/0x1c| el0t_64_irq+0x198/0x19c| Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800)| ---[ end trace 0000000000000000 ]---Fix this by having restore_za_context() ensure that the task's sve_stateis allocated, matching what we do when taking an SME trap. Any liveSVE/SSVE state (which is restored earlier from a separate signalcontext) must be preserved, and hence this is not zeroed.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-24515 Severity: Moderate CVSS3 score: 5.5

Description: In libexpat before 2.7.4, XML_ExternalEntityParserCreate does not copy unknown encoding handler user data.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libexpat1 > 0-0 (version in image is 2.7.1-160000.2.2).

CVE-2025-64718 Severity: Moderate CVSS3 score: 5.4

Description: js-yaml is a JavaScript YAML parser and dumper. In js-yaml before 4.1.1 and 3.14.2, it's possible for an attacker to modify the prototype of the result of a parsed yaml document via prototype pollution (`__proto__`). All users who parse untrusted yaml documents may be impacted. The problem is patched in js-yaml 4.1.1 and 3.14.2. Users can protect against this kind of attack on the server by using `node --disable-proto=delete` or `deno` (in Deno, pollution protection is on by default).

Packages affected:

cockpit-subscriptions < 12.1-160000.1.1 (version in image is 12-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2023-54118 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: setup GPIO controller later in probeThe GPIO controller component of the sc16is7xx driver is setup tooearly, which can result in a race condition where another device triesto utilise the GPIO lines before the sc16is7xx device has finishedinitialising.This issue manifests itself as an Oops when the GPIO lines are configured: Unable to handle kernel read from unreadable memory at virtual address ... pc : sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] lr : sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx] ... Call trace: sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] gpiod_direction_output_raw_commit+0x64/0x318 gpiod_direction_output+0xb0/0x170 create_gpio_led+0xec/0x198 gpio_led_probe+0x16c/0x4f0 platform_drv_probe+0x5c/0xb0 really_probe+0xe8/0x448 driver_probe_device+0xe8/0x138 __device_attach_driver+0x94/0x118 bus_for_each_drv+0x8c/0xe0 __device_attach+0x100/0x1b8 device_initial_probe+0x28/0x38 bus_probe_device+0xa4/0xb0 deferred_probe_work_func+0x90/0xe0 process_one_work+0x1c4/0x480 worker_thread+0x54/0x430 kthread+0x138/0x150 ret_from_fork+0x10/0x1cThis patch moves the setup of the GPIO controller functions to later in theprobe function, ensuring the sc16is7xx device has already finishedinitialising by the time other devices try to make use of the GPIO lines.The error handling has also been reordered to reflect the newinitialisation order.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-52615 Severity: Moderate CVSS3 score: 5.3

Description: A flaw was found in Avahi-daemon, which relies on fixed source ports for wide-area DNS queries. This issue simplifies attacks where malicious DNS responses are injected.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libavahi-client3 < 0.8-160000.3.1 (version in image is 0.8-160000.2.2).

CVE-2025-11083 Severity: Moderate CVSS3 score: 5.3

Description: A vulnerability has been found in GNU Binutils 2.45. The affected element is the function elf_swap_shdr in the library bfd/elfcode.h of the component Linker. The manipulation leads to heap-based buffer overflow. The attack must be carried out locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 9ca499644a21ceb3f946d1c179c38a83be084490. To fix this issue, it is recommended to deploy a patch. The code maintainer replied with "[f]ixed for 2.46".

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-14524 Severity: Moderate CVSS3 score: 5.3

Description: When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transferperforms a cross-protocol redirect to a second URL that uses an IMAP, LDAP,POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the newtarget host.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
curl < 8.14.1-160000.4.1 (version in image is 8.14.1-160000.2.2).

CVE-2025-14819 Severity: Moderate CVSS3 score: 5.3

Description: When doing TLS related transfers with reused easy or multi handles andaltering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentallyreuse a CA store cached in memory for which the partial chain option wasreversed. Contrary to the user's wishes and expectations. This could makelibcurl find and accept a trust chain that it otherwise would not.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
curl < 8.14.1-160000.4.1 (version in image is 8.14.1-160000.2.2).

CVE-2025-15079 Severity: Moderate CVSS3 score: 5.3

Description: When doing SSH-based transfers using either SCP or SFTP, and setting theknown_hosts file, libcurl could still mistakenly accept connecting to hosts*not present* in the specified file if they were added as recognized in thelibssh *global* known_hosts file.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
curl < 8.14.1-160000.4.1 (version in image is 8.14.1-160000.2.2).

CVE-2025-38157 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k_htc: Abort software beacon handling if disabledA malicious USB device can send a WMI_SWBA_EVENTID event from anath9k_htc-managed device before beaconing has been enabled. This causesa device-by-zero error in the driver, leading to either a crash or anout of bounds read.Prevent this by aborting the handling in ath9k_htc_swba() if beacons arenot enabled.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38173 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: marvell/cesa - Handle zero-length skcipher requestsDo not access random memory for zero-length skcipher requests.Just return 0.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38217 Severity: Moderate CVSS3 score: 5.3

Description: 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] twicewithout holding any locks. It is first checked againstFTS_FAN_SOURCE_INVALID, and if the check passes, it is read againwhen 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 ofdata->fan_source[channel] between the check and its use. If the valueis changed to FTS_FAN_SOURCE_INVALID (0xff) during this window, theBIT() 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 isundefined behavior and can lead to a crash or incorrect values beingreturned to userspace.Fix this by reading data->fan_source[channel] into a local variableonce, eliminating the race condition. Additionally, add a bounds checkto ensure the value is less than BITS_PER_LONG before passing it tothe BIT() macro, making the code more robust against undefined behavior.This possible bug was found by an experimental static analysis tooldeveloped by our team.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38220 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: only dirty folios when data journaling regular filesfstest generic/388 occasionally reproduces a crash that looks asfollows:BUG: kernel NULL pointer dereference, address: 0000000000000000...Call Trace: 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. Thepartial block zeroing code in the truncate path callsext4_dirty_journalled_data() -> folio_mark_dirty(). The latter callsmapping->a_ops->dirty_folio(), but symlink inodes are not assigned ana_ops vector in ext4, hence the crash.To avoid this problem, update the ext4_dirty_journalled_data() helper toonly mark the folio dirty on regular files (for which a_ops isassigned). This also matches the journaling logic in the ext4_symlink()creation path, where ext4_handle_dirty_metadata() is called directly.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38242 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:mm: userfaultfd: fix race of userfaultfd_move and swap cacheThis commit fixes two kinds of races, they may have different results:Barry reported a BUG_ON in commit c50f8e6053b0, we may see the sameBUG_ON if the filemap lookup returned NULL and folio is added to swapcache after that.If another kind of race is triggered (folio changed after lookup) wemay see RSS counter is corrupted:[ 406.893936] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0type:MM_ANONPAGES val:-1[ 406.894071] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0type:MM_SHMEMPAGES val:1Because the folio is being accounted to the wrong VMA.I'm not sure if there will be any data corruption though, seems no. The issues above are critical already.On seeing a swap entry PTE, userfaultfd_move does a lockless swap cachelookup, and tries to move the found folio to the faulting vma. Currently,it relies on checking the PTE value to ensure that the moved folio stillbelongs to the src swap entry and that no new folio has been added to theswap cache, which turns out to be unreliable.While working and reviewing the swap table series with Barry, followingexisting races are observed and reproduced [1]:In the example below, move_pages_pte is moving src_pte to dst_pte, wheresrc_pte is a swap entry PTE holding swap entry S1, and S1 is not in theswap cache:CPU1 CPU2userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Here it got entry = S1 ... < interrupted> ... // folio A is a new allocated folio // and get installed into src_pte // src_pte now points to folio A, S1 // has swap count == 0, it can be freed // by folio_swap_swap or swap // allocator's reclaim. // folio B is a folio in another VMA. // S1 is freed, folio B can use it // for swap out with no problem. ... folio = filemap_get_folio(S1) // Got folio B here !!! ... < interrupted again> ... // Now S1 is free to be used again. // Now src_pte is a swap entry PTE // holding S1 again. folio_trylock(folio) move_swap_pte double_pt_lock is_pte_pages_stable // Check passed because src_pte == S1 folio_move_anon_rmap(...) // Moved invalid folio B here !!!The race window is very short and requires multiple collisions of multiplerare events, so it's very unlikely to happen, but with a deliberatelyconstructed reproducer and increased time window, it can be reproducedeasily.This can be fixed by checking if the folio returned by filemap is thevalid swap cache folio after acquiring the folio lock.Another similar race is possible: filemap_get_folio may return NULL, butfolio (A) could be swapped in and then swapped out again using the sameswap entry after the lookup. In such a case, folio (A) may remain in theswap cache, so it must be moved too:CPU1 CPU2userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Here it got entry = S1, and S1 is not in swap cache folio = filemap_get---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38338 Severity: Moderate CVSS3 score: 5.3

Description: 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 byanother 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), nobodynotices 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_folioThe problem is that nfs_read_add_folio() is not supposed to unlock thefolio if fscache is enabled, and a nfs_netfs_folio_unlock() check ismissing 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: netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0 worker_thread+0x295/0x3a0Most of the time, however, processes just get stuck forever infolio_wait_bit_common(), waiting for `PG_locked` to disappear, whichnever happens because nobody is really holding the folio lock.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38372 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix unsafe xarray access in implicit ODP handling__xa_store() and __xa_erase() were used without holding the proper lock,which led to a lockdep warning due to unsafe RCU usage. This patchreplaces them with xa_store() and xa_erase(), which perform the necessarylocking internally. ============================= WARNING: suspicious RCPU usage 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1 Not tainted ----------------------------- ./include/linux/xarray.h:1211 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by kworker/u136:0/219: at: process_one_work+0xbe4/0x15f0 process_one_work+0x75c/0x15f0 pagefault_mr+0x9a5/0x1390 [mlx5_ib] stack backtrace: CPU: 14 UID: 0 PID: 219 Comm: kworker/u136:0 Not tainted 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib] Call Trace: dump_stack_lvl+0xa8/0xc0 lockdep_rcu_suspicious+0x1e6/0x260 xas_create+0xb8a/0xee0 xas_store+0x73/0x14c0 __xa_store+0x13c/0x220 ? xa_store_range+0x390/0x390 ? spin_bug+0x1d0/0x1d0 pagefault_mr+0xcb5/0x1390 [mlx5_ib] ? _raw_spin_unlock+0x1f/0x30 mlx5_ib_eqe_pf_action+0x3be/0x2620 [mlx5_ib] ? lockdep_hardirqs_on_prepare+0x400/0x400 ? mlx5_ib_invalidate_range+0xcb0/0xcb0 [mlx5_ib] process_one_work+0x7db/0x15f0 ? pwq_dec_nr_in_flight+0xda0/0xda0 ? assign_work+0x168/0x240 worker_thread+0x57d/0xcd0 ? rescuer_thread+0xc40/0xc40 kthread+0x3b3/0x800 ? kthread_is_per_cpu+0xb0/0xb0 ? lock_downgrade+0x680/0x680 ? do_raw_spin_lock+0x12d/0x270 ? spin_bug+0x1d0/0x1d0 ? finish_task_switch.isra.0+0x284/0x9e0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? kthread_is_per_cpu+0xb0/0xb0 ret_from_fork+0x2d/0x70 ? kthread_is_per_cpu+0xb0/0xb0 ret_from_fork_asm+0x11/0x20

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38450 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_sta_set_decap_offload()Add a NULL check for msta->vif before accessing its members to preventa kernel panic in AP mode deployment. This also fix the issue reportedin [1].The crash occurs when this function is triggered before the station isfully initialized. The call trace shows a page fault atmt7925_sta_set_decap_offload() due to accessing resources when msta->vifis NULL.Fix this by adding an early return if msta->vif is NULL and also checkwcid.sta is ready. This ensures we only proceed with decap offloadconfiguration when the station's state is properly initialized.[14739.655703] Unable to handle kernel paging request at virtual address ffffffffffffffa0[14739.811820] CPU: 0 UID: 0 PID: 895854 Comm: hostapd Tainted: G[14739.821394] Tainted: [C]=CRAP, [O]=OOT_MODULE[14739.825746] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)[14739.831577] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[14739.838538] pc : mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common][14739.845271] lr : mt7925_sta_set_decap_offload+0x58/0x1b8 [mt7925_common][14739.851985] sp : ffffffc085efb500[14739.855295] x29: ffffffc085efb500 x28: 0000000000000000 x27: ffffff807803a158[14739.862436] x26: ffffff8041ececb8 x25: 0000000000000001 x24: 0000000000000001[14739.869577] x23: 0000000000000001 x22: 0000000000000008 x21: ffffff8041ecea88[14739.876715] x20: ffffff8041c19ca0 x19: ffffff8078031fe0 x18: 0000000000000000[14739.883853] x17: 0000000000000000 x16: ffffffe2aeac1110 x15: 000000559da48080[14739.890991] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000[14739.898130] x11: 0a10020001008e88 x10: 0000000000001a50 x9 : ffffffe26457bfa0[14739.905269] x8 : ffffff8042013bb0 x7 : ffffff807fb6cbf8 x6 : dead000000000100[14739.912407] x5 : dead000000000122 x4 : ffffff80780326c8 x3 : 0000000000000000[14739.919546] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8041ececb8[14739.926686] Call trace:[14739.929130] mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common][14739.935505] ieee80211_check_fast_rx+0x19c/0x510 [mac80211][14739.941344] _sta_info_move_state+0xe4/0x510 [mac80211][14739.946860] sta_info_move_state+0x1c/0x30 [mac80211][14739.952116] sta_apply_auth_flags.constprop.0+0x90/0x1b0 [mac80211][14739.958708] sta_apply_parameters+0x234/0x5e0 [mac80211][14739.964332] ieee80211_add_station+0xdc/0x190 [mac80211][14739.969950] nl80211_new_station+0x46c/0x670 [cfg80211][14739.975516] genl_family_rcv_msg_doit+0xdc/0x150[14739.980158] genl_rcv_msg+0x218/0x298[14739.983830] netlink_rcv_skb+0x64/0x138[14739.987670] genl_rcv+0x40/0x60[14739.990816] netlink_unicast+0x314/0x380[14739.994742] netlink_sendmsg+0x198/0x3f0[14739.998664] __sock_sendmsg+0x64/0xc0[14740.002324] ____sys_sendmsg+0x260/0x298[14740.006242] ___sys_sendmsg+0xb4/0x110

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38462 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Fix transport_{g2h,h2g} TOCTOUvsock_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 potentialnull-ptr-deref.KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]RIP: 0010:vsock_find_cid+0x47/0x90Call 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/0x53KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0Call Trace: __x64_sys_ioctl+0x12d/0x190 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38478 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix initialization of data for instructions that write to subdeviceSome Comedi subdevice instruction handlers are known to accessinstruction data elements beyond the first `insn->n` elements in somecases. The `do_insn_ioctl()` and `do_insnlist_ioctl()` functionsallocate at least `MIN_SAMPLES` (16) data elements to deal with this,but they do not initialize all of that. For Comedi instruction codesthat write to the subdevice, the first `insn->n` data elements arecopied from user-space, but the remaining elements are leftuninitialized. That could be a problem if the subdevice instructionhandler reads the uninitialized data. Ensure that the first`MIN_SAMPLES` elements are initialized before calling these instructionhandlers, filling the uncopied elements with 0. For`do_insnlist_ioctl()`, the same data buffer elements are used forhandling a list of instructions, so ensure the first `MIN_SAMPLES`elements are initialized for each instruction that writes to thesubdevice.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38480 Severity: Moderate CVSS3 score: 5.3

Description: 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 thesupplied `data[0]` value is a valid copy from user memory. It will atleast exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in"comedi_fops.c" ensure at lease `MIN_SAMPLES` (16) elements areallocated. However, if `insn->n` is 0 (which is allowable for`INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may containuninitialized data, and certainly contains invalid data, possibly from adifferent instruction in the array of instructions handled by`do_insnlist_ioctl()`. This will result in an incorrect value beingwritten to the digital output channel (or to the digital input/outputchannel if configured as an output), and may be reflected in theinternal saved state of the channel.Fix it by returning 0 early if `insn->n` is 0, before reaching the codethat accesses `data[0]`. Previously, the function always returned 1 onsuccess, but it is supposed to be the number of data samples actuallyread or written up to `insn->n`, which is 0 in this case.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38482 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: das6402: Fix bit shift out of boundsWhen 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, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38483 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: das16m1: Fix bit shift out of boundsWhen 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, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38497 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: configfs: Fix OOB read on empty string writeWhen 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 beginningof os_desc_qw_sign_store() and webusb_landingPage_store() to handlethe zero-length input case gracefully by returning immediately.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38527 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free in cifs_oplock_breakA race condition can occur in cifs_oplock_break() leading to ause-after-free of the cinode structure when unmounting: cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAFThe issue occurs when umount has already released its reference to thesuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), thisreleases the last reference, triggering the immediate cleanup of allinodes under RCU. However, cifs_oplock_break() continues to access thecinode after this point, resulting in use-after-free.Fix this by holding an extra reference to the superblock during theentire oplock break operation. This ensures that the superblock andits inodes remain valid until the oplock break completes.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38539 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Add down_write(trace_event_sem) when adding trace eventWhen a module is loaded, it adds trace events defined by the module. Itmay also need to modify the modules trace printk formats to replace enumnames with their values.If two modules are loaded at the same time, the adding of the event to theftrace_events list can corrupt the walking of the list in the code that ismodifying the printk format strings and crash the kernel.The addition of the event should take the trace_event_sem for write whileit adds the new event.Also add a lockdep_assert_held() on that semaphore in__trace_add_event_dirs() as it iterates the list.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38646 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz bandWith a quite rare chance, RX report might be problematic to make SW thinka packet is received on 6 GHz band even if the chip does not support 6 GHzband actually. Since SW won't initialize stuffs for unsupported bands, NULLdereference will happen then in the sequence, rtw89_vif_rx_stats_iter() ->rtw89_core_cancel_6ghz_probe_tx(). So, add a check to avoid it.The following is a crash log for this case. BUG: kernel NULL pointer dereference, address: 0000000000000032 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1907 Comm: irq/131-rtw89_p Tainted: G U 6.6.56-05896-g89f5fb0eb30b #1 (HASH:1400 4) Hardware name: Google Telith/Telith, BIOS Google_Telith.15217.747.0 11/12/2024 RIP: 0010:rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core] Code: 4c 89 7d c8 48 89 55 c0 49 8d 44 24 02 48 89 45 b8 45 31 ff eb 11 41 c6 45 3a 01 41 b7 01 4d 8b 6d 00 4d 39 f5 74 42 8b 43 10 <41> 33 45 32 0f b7 4b 14 66 41 33 4d 36 0f b7 c9 09 c1 74 d8 4d 85 RSP: 0018:ffff9f3080138ca0 EFLAGS: 00010246 RAX: 00000000b8bf5770 RBX: ffff91b5e8c639c0 RCX: 0000000000000011 RDX: ffff91b582de1be8 RSI: 0000000000000000 RDI: ffff91b5e8c639e6 RBP: ffff9f3080138d00 R08: 0000000000000000 R09: 0000000000000000 R10: ffff91b59de70000 R11: ffffffffc069be50 R12: ffff91b5e8c639e4 R13: 0000000000000000 R14: ffff91b5828020b8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff91b8efa40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000032 CR3: 00000002bf838000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x4f/0xa0 ? asm_exc_page_fault+0x22/0x30 ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ? rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core (HASH:1400 5)] __iterate_interfaces+0x59/0x110 [mac80211 (HASH:1400 6)] ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)] ieee80211_iterate_active_interfaces_atomic+0x36/0x50 [mac80211 (HASH:1400 6)] rtw89_core_rx_to_mac80211+0xfd/0x1b0 [rtw89_core (HASH:1400 5)] rtw89_core_rx+0x43a/0x980 [rtw89_core (HASH:1400 5)]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39746 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: shutdown driver when hardware is unreliableIn rare cases, ath10k may lose connection with the PCIe bus due tosome unknown reasons, which could further lead to system crashes duringresuming due to watchdog timeout:ath10k_pci 0000:01:00.0: wmi command 20486 timeout, restarting hardwareath10k_pci 0000:01:00.0: already restartingath10k_pci 0000:01:00.0: failed to stop WMI vdev 0: -11ath10k_pci 0000:01:00.0: failed to stop vdev 0: -11ieee80211 phy0: PM: **** DPM device timeout ****Call Trace: panic+0x125/0x315 dpm_watchdog_set+0x54/0x54 dpm_watchdog_handler+0x57/0x57 call_timer_fn+0x31/0x13cAt this point, all WMI commands will timeout and attempt to restartdevice. So set a threshold for consecutive restart failures. If thethreshold is exceeded, consider the hardware is unreliable and allath10k operations should be skipped to avoid system crash.fail_cont_count and pending_recovery are atomic variables, anddo not involve complex conditional logic. Therefore, even if recoverycheck and reconfig complete are executed concurrently, the recoverymechanism will not be broken.Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39788 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPEOn Google gs101, the number of UTP transfer request slots (nutrs) is 32,and in this case the driver ends up programming the UTRL_NEXUS_TYPEincorrectly as 0.This is because the left hand side of the shift is 1, which is of typeint, i.e. 31 bits wide. Shifting by more than that width results inundefined behaviour.Fix this by switching to the BIT() macro, which applies correct typecasting as required. This ensures the correct value is written toUTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shiftwarning: UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21 shift exponent 32 is too large for 32-bit type 'int'For consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPEwrite.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39812 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: initialize more fields in sctp_v6_from_sk()syzbot found that sin6_scope_id was not properly initialized,leading to undefined behavior.Clear sin6_scope_id and sin6_flowinfo.BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983 sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390 sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452 sctp_get_port net/sctp/socket.c:8523 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930 x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fLocal variable addr.i.i created at: sctp_get_port net/sctp/socket.c:8515 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39927 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix race condition validating r_parent before applying stateAdd validation to ensure the cached parent directory inode matches thedirectory info in MDS replies. This prevents client-side race conditionswhere concurrent operations (e.g. rename) cause r_parent to become stalebetween request initiation and reply processing, which could lead toapplying state changes to incorrect directory inodes.[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ]

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39964 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Disallow concurrent writes in af_alg_sendmsgIssuing two writes to the same af_alg socket is bogus as thedata will be interleaved in an unpredictable fashion. Furthermore,concurrent writes may create inconsistencies in the internalsocket state.Disallow this by adding a new ctx->write field that indiciatesexclusive ownership for writing.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40003 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: mscc: ocelot: Fix use-after-free caused by cyclic delayed workThe origin code calls cancel_delayed_work() in ocelot_stats_deinit()to cancel the cyclic delayed work item ocelot->stats_work. However,cancel_delayed_work() may fail to cancel the work item if it is alreadyexecuting. While destroy_workqueue() does wait for all pending work itemsin the work queue to complete before destroying the work queue, it cannotprevent the delayed work item from being rescheduled within theocelot_check_stats_work() function. This limitation exists because thedelayed work item is only enqueued into the work queue after its timerexpires. Before the timer expiration, destroy_workqueue() has no visibilityof this pending work item. Once the work queue appears empty,destroy_workqueue() proceeds with destruction. When the timer eventuallyexpires, the delayed work item gets queued again, leading to the followingwarning:workqueue: cannot queue ocelot_check_stats_work on wq ocelot-switch-statsWARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2255 __queue_work+0x875/0xaf0...RIP: 0010:__queue_work+0x875/0xaf0...RSP: 0018:ffff88806d108b10 EFLAGS: 00010086RAX: 0000000000000000 RBX: 0000000000000101 RCX: 0000000000000027RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffff88806d123e88RBP: ffffffff813c3170 R08: 0000000000000000 R09: ffffed100da247d2R10: ffffed100da247d1 R11: ffff88806d123e8b R12: ffff88800c00f000R13: ffff88800d7285c0 R14: ffff88806d0a5580 R15: ffff88800d7285a0FS: 0000000000000000(0000) GS:ffff8880e5725000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe18e45ea10 CR3: 0000000005e6c000 CR4: 00000000000006f0Call Trace: ? kasan_report+0xc6/0xf0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? __pfx_delayed_work_timer_fn+0x10/0x10 call_timer_fn+0x25/0x1c0 __run_timer_base.part.0+0x3be/0x8c0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x1c0/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...The following diagram reveals the cause of the above warning:CPU 0 (remove) | CPU 1 (delayed work callback)mscc_ocelot_remove() | ocelot_deinit() | ocelot_check_stats_work() ocelot_stats_deinit() | cancel_delayed_work()| ... | queue_delayed_work() destroy_workqueue() | (wait a time) | __queue_work() //UAFThe above scenario actually constitutes a UAF vulnerability.The ocelot_stats_deinit() is only invoked when initializationfailure or resource destruction, so we must ensure that anydelayed work items cannot be rescheduled.Replace cancel_delayed_work() with disable_delayed_work_sync()to guarantee proper cancellation of the delayed work item andensure completion of any currently executing work before theworkqueue is deallocated.A deadlock concern was considered: ocelot_stats_deinit() is calledin a process context and is not holding any locks that the delayedwork item might also need. Therefore, the use of the _sync() variantis safe here.This bug was identified through static analysis. To reproduce theissue and validate the fix, I simulated ocelot-swit---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40027 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: fix double req put in p9_fd_cancelledSyzkaller reports a KASAN issue as below:general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f]CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:__list_del include/linux/list.h:114 [inline]RIP: 0010:__list_del_entry include/linux/list.h:137 [inline]RIP: 0010:list_del include/linux/list.h:148 [inline]RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734Call Trace: p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 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/0xd8This happens because of a race condition between:- The 9p client sending an invalid flush request and later cleaning it up;- The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ...Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list inp9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystemclient where the req_list could be deleted simultaneously by bothp9_read_work and p9_fd_cancelled functions, but for the case where req->statusequals REQ_STATUS_RCVD.Update the check for req->status in p9_fd_cancelled to skip processing notjust received requests, but anything that is not SENT, as whateverchanged the state from SENT also removed the request from its list.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.[updated the check from status == RECV || status == ERROR to status != SENT]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40171 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-fc: move lsop put work to nvmet_fc_ls_req_opIt's possible for more than one async command to be in flight from__nvmet_fc_send_ls_req. For each command, a tgtport reference is taken.In the current code, only one put work item is queued at a time, whichresults in a leaked reference.To fix this, move the work item to the nvmet_fc_ls_req_op struct, whichalready tracks all resources related to the command.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40183 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}Cilium has a BPF egress gateway feature which forces outgoing K8s Podtraffic to pass through dedicated egress gateways which then SNAT thetraffic in order to interact with stable IPs outside the cluster.The traffic is directed to the gateway via vxlan tunnel in collect mdmode. A recent BPF change utilized the bpf_redirect_neigh() helper toforward packets after the arrival and decap on vxlan, which turned outover time that the kmalloc-256 slab usage in kernel was ever-increasing.The issue was that vxlan allocates the metadata_dst object and attachesit through a fake dst entry to the skb. The latter was never releasedthough given bpf_redirect_neigh() was merely setting the new dst entryvia skb_dst_set() without dropping an existing one first.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40303 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: ensure no dirty metadata is written back for an fs with errors[BUG]During development of a minor feature (make sure all btrfs_bio::end_io()is called in task context), I noticed a crash in generic/388, wheremetadata writes triggered new works after btrfs_stop_all_workers().It turns out that it can even happen without any code modification, justusing RAID5 for metadata and the same workload from generic/388 is goingto trigger the use-after-free.[CAUSE]If btrfs hits an error, the fs is marked as error, no newtransaction is allowed thus metadata is in a frozen state.But there are some metadata modifications before that error, and they arestill in the btree inode page cache.Since there will be no real transaction commit, all those dirty foliosare just kept as is in the page cache, and they can not be invalidatedby invalidate_inode_pages2() call inside close_ctree(), because they aredirty.And finally after btrfs_stop_all_workers(), we call iput() on btreeinode, which triggers writeback of those dirty metadata.And if the fs is using RAID56 metadata, this will trigger RMW and queuenew works into rmw_workers, which is already stopped, causing warningfrom queue_work() and use-after-free.[FIX]Add a special handling for write_one_eb(), that if the fs is already inan error state, immediately mark the bbio as failure, instead of reallysubmitting them.Then during close_ctree(), iput() will just discard all those dirtytree blocks without really writing them back, thus no more new jobs foralready stopped-and-freed workqueues.The extra discard in write_one_eb() also acts as an extra safenet.E.g. the transaction abort is triggered by some extent/free spacetree corruptions, and since extent/free space tree is already corruptedsome tree blocks may be allocated where they shouldn't be (overwritingexisting tree blocks). In that case writing them back will furthercorrupting the fs.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40322 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: bitblit: bound-check glyph index in bit_putcs*bit_putcs_aligned()/unaligned() derived the glyph pointer from thecharacter value masked by 0xff/0x1ff, which may exceed the actual font'sglyph count and read past the end of the built-in font array.Clamp the index to the actual glyph count before computing the address.This fixes a global out-of-bounds read reported by syzbot.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-58058 Severity: Moderate CVSS3 score: 5.3

Description: xz is a pure golang package for reading and writing xz-compressed files. Prior to version 0.5.14, it is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the specification. Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. This issue has been patched in version 0.5.14.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
google-osconfig-agent > 0-0 (version in image is 20250416.02-160000.2.2).

CVE-2025-61984 Severity: Moderate CVSS3 score: 5.3

Description: ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
openssh < 10.0p2-160000.3.1 (version in image is 10.0p2-160000.2.2).

CVE-2025-61985 Severity: Moderate CVSS3 score: 5.3

Description: ssh in OpenSSH before 10.1 allows the '\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
openssh < 10.0p2-160000.3.1 (version in image is 10.0p2-160000.2.2).

CVE-2025-66199 Severity: Moderate CVSS3 score: 5.3

Description: Issue summary: A TLS 1.3 connection using certificate compression can beforced to allocate a large buffer before decompression without checkingagainst the configured certificate size limit.Impact summary: An attacker can cause per-connection memory allocations ofup to approximately 22 MiB and extra CPU work, potentially leading toservice degradation or resource exhaustion (Denial of Service).In affected configurations, the peer-supplied uncompressed certificatelength from a CompressedCertificate message is used to grow a heap bufferprior to decompression. This length is not bounded by the max_cert_listsetting, which otherwise constrains certificate message sizes. An attackercan exploit this to cause large per-connection allocations followed byhandshake failure. No memory corruption or information disclosure occurs.This issue only affects builds where TLS 1.3 certificate compression iscompiled in (i.e., not OPENSSL_NO_COMP_ALG) and at least one compressionalgorithm (brotli, zlib, or zstd) is available, and where the compressionextension is negotiated. Both clients receiving a server CompressedCertificateand servers in mutual TLS scenarios receiving a client CompressedCertificateare affected. Servers that do not request client certificates are notvulnerable to client-initiated attacks.Users can mitigate this issue by setting SSL_OP_NO_RX_CERTIFICATE_COMPRESSIONto disable receiving compressed certificates.The FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue,as the TLS implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.5.1 (version in image is 3.5.0-160000.3.2).

CVE-2025-66418 Severity: Moderate CVSS3 score: 5.3

Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.24 and prior to 2.6.0, the number of links in the decompression chain was unbounded allowing a malicious server to insert a virtually unlimited number of compression steps leading to high CPU usage and massive memory allocation for the decompressed data. This vulnerability is fixed in 2.6.0.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313-urllib3 < 2.5.0-160000.4.1 (version in image is 2.5.0-160000.2.2).

CVE-2025-66471 Severity: Moderate CVSS3 score: 5.3

Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.0 and prior to 2.6.0, the Streaming API improperly handles highly compressed data. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation. The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313-urllib3 < 2.5.0-160000.4.1 (version in image is 2.5.0-160000.2.2).

CVE-2025-68307 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBsThe driver lacks the cleanup of failed transfers of URBs. This reduces thenumber of available URBs per error by 1. This leads to reduced performanceand ultimately to a complete stop of the transmission.If the sending of a bulk URB fails do proper cleanup:- increase netdev stats- mark the echo_sbk as free- free the driver's context and do accounting- wake the send queue

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68315 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to detect potential corrupted nid in free_nid_listAs reported, on-disk footer.ino and footer.nid is the same andout-of-range, let's add sanity check on f2fs_alloc_nid() to detectany potential corruption in free_nid_list.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-69225 Severity: Moderate CVSS3 score: 5.3

Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below contain parser logic which allows non-ASCII decimals to be present in the Range header. There is no known impact, but there is the possibility that there's a method to exploit a request smuggling vulnerability. This issue is fixed in version 3.13.3.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313-aiohttp > 0-0 (version in image is 3.11.16-160000.2.2).

CVE-2025-69226 Severity: Moderate CVSS3 score: 5.3

Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below enable an attacker to ascertain the existence of absolute path components through the path normalization logic for static files meant to prevent path traversal. If an application uses web.static() (not recommended for production deployments), it may be possible for an attacker to ascertain the existence of path components. This issue is fixed in version 3.13.3.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313-aiohttp > 0-0 (version in image is 3.11.16-160000.2.2).

CVE-2025-69418 Severity: Moderate CVSS3 score: 5.3

Description: Issue summary: When using the low-level OCB API directly with AES-NI or
other hardware-accelerated code paths, inputs whose length is not a multiple
of 16 bytes can leave the final partial block unencrypted and unauthenticated.

Impact summary: The trailing 1-15 bytes of a message may be exposed in
cleartext on encryption and are not covered by the authentication tag,
allowing an attacker to read or tamper with those bytes without detection.

The low-level OCB encrypt and decrypt routines in the hardware-accelerated
stream path process full 16-byte blocks but do not advance the input/output
pointers. The subsequent tail-handling code then operates on the original
base pointers, effectively reprocessing the beginning of the buffer while
leaving the actual trailing bytes unprocessed. The authentication checksum
also excludes the true tail bytes.

However, typical OpenSSL consumers using EVP are not affected because the
higher-level EVP and provider OCB implementations split inputs so that full
blocks and trailing partial blocks are processed in separate calls, avoiding
the problematic code path. Additionally, TLS does not use OCB ciphersuites.
The vulnerability only affects applications that call the low-level
CRYPTO_ocb128_encrypt() or CRYPTO_ocb128_decrypt() functions directly with
non-block-aligned lengths in a single call on hardware-accelerated builds.
For these reasons the issue was assessed as Low severity.

The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected
by this issue, as OCB mode is not a FIPS-approved algorithm.

OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.

OpenSSL 1.0.2 is not affected by this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.5.1 (version in image is 3.5.0-160000.3.2).

CVE-2025-69420 Severity: Moderate CVSS3 score: 5.3

Description: Issue summary: A type confusion vulnerability exists in the TimeStamp Responseverification code where an ASN1_TYPE union member is accessed without firstvalidating the type, causing an invalid or NULL pointer dereference whenprocessing a malformed TimeStamp Response file.Impact summary: An application calling TS_RESP_verify_response() with amalformed TimeStamp Response can be caused to dereference an invalid orNULL pointer when reading, resulting in a Denial of Service.The functions ossl_ess_get_signing_cert() and ossl_ess_get_signing_cert_v2()access the signing cert attribute value without validating its type.When the type is not V_ASN1_SEQUENCE, this results in accessing invalid memorythrough the ASN1_TYPE union, causing a crash.Exploiting this vulnerability requires an attacker to provide a malformedTimeStamp Response to an application that verifies timestamp responses. TheTimeStamp protocol (RFC 3161) is not widely used and the impact of theexploit is just a Denial of Service. For these reasons the issue wasassessed as Low severity.The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the TimeStamp Response implementation is outside the OpenSSL FIPS moduleboundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.OpenSSL 1.0.2 is not affected by this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.5.1 (version in image is 3.5.0-160000.3.2).

CVE-2025-71093 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:e1000: fix OOB in e1000_tbi_should_accept()In e1000_tbi_should_accept() we read the last byte of the frame via'data[length - 1]' to evaluate the TBI workaround. If the descriptor-reported length is zero or larger than the actual RX buffer size, thisread goes out of bounds and can hit unrelated slab objects. The issueis observed from the NAPI receive path (e1000_clean_rx_irq):==================================================================BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790Read of size 1 at addr ffff888014114e54 by task sshd/363CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x5a/0x74 print_address_description+0x7b/0x440 print_report+0x101/0x200 kasan_report+0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110 e1000_clean+0xde2/0x3c10 __napi_poll+0x98/0x380 net_rx_action+0x491/0xa20 __do_softirq+0x2c9/0x61d do_softirq+0xd1/0x120 __local_bh_enable_ip+0xfe/0x130 ip_finish_output2+0x7d5/0xb00 __ip_queue_xmit+0xe24/0x1ab0 __tcp_transmit_skb+0x1bcb/0x3340 tcp_write_xmit+0x175d/0x6bd0 __tcp_push_pending_frames+0x7b/0x280 tcp_sendmsg_locked+0x2e4f/0x32d0 tcp_sendmsg+0x24/0x40 sock_write_iter+0x322/0x430 vfs_write+0x56c/0xa60 ksys_write+0xd1/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f511b476b10Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 Allocated by task 1: __kasan_krealloc+0x131/0x1c0 krealloc+0x90/0xc0 add_sysfs_param+0xcb/0x8a0 kernel_add_sysfs_param+0x81/0xd4 param_sysfs_builtin+0x138/0x1a6 param_sysfs_init+0x57/0x5b do_one_initcall+0x104/0x250 do_initcall_level+0x102/0x132 do_initcalls+0x46/0x74 kernel_init_freeable+0x28f/0x393 kernel_init+0x14/0x1a0 ret_from_fork+0x22/0x30The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800]The buggy address belongs to the physical page:page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0flags: 0x100000000010200(slab|head|node=0|zone=1)raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detected==================================================================This happens because the TBI check unconditionally dereferences the lastbyte without validating the reported length first: u8 last_byte = *(data + length - 1);Fix by rejecting the frame early if the length is zero, or if it exceedsadapter->rx_buffer_len. This preserves the TBI workaround semantics forvalid frames and prevents touching memory beyond the RX buffer.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-8177 Severity: Moderate CVSS3 score: 5.3

Description: A vulnerability was found in LibTIFF up to 4.7.0. It has been rated as critical. This issue affects the function setrow of the file tools/thumbnail.c. The manipulation leads to buffer overflow. An attack has to be approached locally. The patch is named e8c9d6c616b19438695fd829e58ae4fde5bfbc22. It is recommended to apply a patch to fix this issue. This vulnerability only affects products that are no longer supported by the maintainer.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libtiff6 < 4.7.1-160000.1.1 (version in image is 4.7.0-160000.2.2).

CVE-2025-9231 Severity: Moderate CVSS3 score: 5.3

Description: Issue summary: A timing side-channel which could potentially allow remoterecovery of the private key exists in the SM2 algorithm implementation on 64 bitARM platforms.Impact summary: A timing side-channel in SM2 signature computations on 64 bitARM platforms could allow recovering the private key by an attacker..While remote key recovery over a network was not attempted by the reporter,timing measurements revealed a timing signal which may allow such an attack.OpenSSL does not directly support certificates with SM2 keys in TLS, and sothis CVE is not relevant in most TLS contexts. However, given that it ispossible to add support for such certificates via a custom provider, coupledwith the fact that in such a custom provider context the private key may berecoverable via remote timing measurements, we consider this to be a Moderateseverity issue.The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by thisissue, as SM2 is not an approved algorithm.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.4.1 (version in image is 3.5.0-160000.3.2).

CVE-2025-9390 Severity: Moderate CVSS3 score: 5.3

Description: A security flaw has been discovered in vim up to 9.1.1615. Affected by this vulnerability is the function main of the file src/xxd/xxd.c of the component xxd. The manipulation results in buffer overflow. The attack requires a local approach. The exploit has been released to the public and may be exploited. Upgrading to version 9.1.1616 addresses this issue. The patch is identified as eeef7c77436a78cd27047b0f5fa6925d56de3cb0. It is recommended to upgrade the affected component.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
vim > 0-0 (version in image is 9.1.1406-160000.3.2).

CVE-2026-0915 Severity: Moderate CVSS3 score: 5.3

Description: Calling getnetbyaddr or getnetbyaddr_r with a configured nsswitch.conf that specifies the library's DNS backend for networks and queries for a zero-valued network in the GNU C Library version 2.0 to version 2.42 can leak stack contents to the configured DNS resolver.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
glibc < 2.40-160000.3.1 (version in image is 2.40-160000.2.2).

CVE-2026-22693 Severity: Moderate CVSS3 score: 5.3

Description: HarfBuzz is a text shaping engine. Prior to version 12.3.0, a null pointer dereference vulnerability exists in the SubtableUnicodesCache::create function located in src/hb-ot-cmap-table.hh. The function fails to check if hb_malloc returns NULL before using placement new to construct an object at the returned pointer address. When hb_malloc fails to allocate memory (which can occur in low-memory conditions or when using custom allocators that simulate allocation failures), it returns NULL. The code then attempts to call the constructor on this null pointer using placement new syntax, resulting in undefined behavior and a Segmentation Fault. This issue has been patched in version 12.3.0.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libharfbuzz-gobject0 > 0-0 (version in image is 11.0.0-160000.2.2).

CVE-2026-22796 Severity: Moderate CVSS3 score: 5.3

Description: Issue summary: A type confusion vulnerability exists in the signatureverification of signed PKCS#7 data where an ASN1_TYPE union member isaccessed without first validating the type, causing an invalid or NULLpointer dereference when processing malformed PKCS#7 data.Impact summary: An application performing signature verification of PKCS#7data or calling directly the PKCS7_digest_from_attributes() function can becaused to dereference an invalid or NULL pointer when reading, resulting ina Denial of Service.The function PKCS7_digest_from_attributes() accesses the message digest attributevalue without validating its type. When the type is not V_ASN1_OCTET_STRING,this results in accessing invalid memory through the ASN1_TYPE union, causinga crash.Exploiting this vulnerability requires an attacker to provide a malformedsigned PKCS#7 to an application that verifies it. The impact of theexploit is just a Denial of Service, the PKCS7 API is legacy and applicationsshould be using the CMS API instead. For these reasons the issue wasassessed as Low severity.The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the PKCS#7 parsing implementation is outside the OpenSSL FIPS moduleboundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenssl3 < 3.5.0-160000.5.1 (version in image is 3.5.0-160000.3.2).

CVE-2026-23025 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:mm/page_alloc: prevent pcp corruption with SMP=nThe kernel test robot has reported: BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28 lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0 CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470 Call Trace: __dump_stack (lib/dump_stack.c:95) dump_stack_lvl (lib/dump_stack.c:123) dump_stack (lib/dump_stack.c:130) spin_dump (kernel/locking/spinlock_debug.c:71) do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?) _raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138) __free_frozen_pages (mm/page_alloc.c:2973) ___free_pages (mm/page_alloc.c:5295) __free_pages (mm/page_alloc.c:5334) tlb_remove_table_rcu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmu_gather.c:227 mm/mmu_gather.c:290) ? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289) ? rcu_core (kernel/rcu/tree.c:?) rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861) rcu_core_si (kernel/rcu/tree.c:2879) handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623) __irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725) irq_exit_rcu (kernel/softirq.c:741) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052) RIP: 0010:_raw_spin_unlock_irqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:194) free_pcppages_bulk (mm/page_alloc.c:1494) drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632) __drain_all_pages (mm/page_alloc.c:2731) drain_all_pages (mm/page_alloc.c:2747) kcompactd (mm/compaction.c:3115) kthread (kernel/kthread.c:465) ? __cfi_kcompactd (mm/compaction.c:3166) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork (arch/x86/kernel/process.c:164) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Matthew has analyzed the report and identified that in drain_page_zone()we are in a section protected by spin_lock(&pcp->lock) and then get aninterrupt that attempts spin_trylock() on the same lock. The code isdesigned to work this way without disabling IRQs and occasionally fail thetrylock with a fallback. However, the SMP=n spinlock implementationassumes spin_trylock() will always succeed, and thus it's normally ano-op. Here the enabled lock debugging catches the problem, but otherwiseit could cause a corruption of the pcp structure.The problem has been introduced by commit 574907741599 ("mm/page_alloc:leave IRQs enabled for per-cpu page allocations"). The pcp locking schemerecognizes the need for disabling IRQs to prevent nesting spin_trylock()sections on SMP=n, but the need to prevent the nesting in spin_lock() hasnot been recognized. Fix it by introducing local wrappers that change thespin_lock() to spin_lock_iqsave() with SMP=n and use them in all placesthat do spin_lock(&pcp->lock).[vbabka@suse.cz: add pcp_ prefix to the spin_lock_irqsave wrappers, per Steven]

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23059 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Sanitize payload size to prevent member overflowIn qla27xx_copy_fpin_pkt() and qla27xx_copy_multiple_pkt(), the frame_sizereported by firmware is used to calculate the copy length intoitem->iocb. However, the iocb member is defined as a fixed-size 64-bytearray within struct purex_item.If the reported frame_size exceeds 64 bytes, subsequent memcpy calls willoverflow the iocb member boundary. While extra memory might be allocated,this cross-member write is unsafe and triggers warnings underCONFIG_FORTIFY_SOURCE.Fix this by capping total_bytes to the size of the iocb member (64 bytes)before allocation and copying. This ensures all copies remain within thebounds of the destination structure member.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40157 Severity: Moderate CVSS3 score: 5.2

Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/i10nm: Skip DIMM enumeration on a disabled memory controllerWhen loading the i10nm_edac driver on some Intel Granite Rapids servers,a call trace may appear as follows: UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16 shift exponent -66 is negative ... __ubsan_handle_shift_out_of_bounds+0x1e3/0x390 skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common] i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac] skx_register_mci+0x159/0x220 [skx_edac_common] i10nm_init+0xcb0/0x1ff0 [i10nm_edac] ...This occurs because some BIOS may disable a memory controller if therearen't any memory DIMMs populated on this memory controller. The DIMMMTRregister of this disabled memory controller contains the invalid value~0, resulting in the call trace above.Fix this call trace by skipping DIMM enumeration on a disabled memorycontroller.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40271 Severity: Moderate CVSS3 score: 5.2

Description: In the Linux kernel, the following vulnerability has been resolved:fs/proc: fix uaf in proc_readdir_de()Pde is erased from subdir rbtree through rb_erase(), but not set the nodeto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()set the erased node to EMPTY, then pde_subdir_next() will return NULL toavoid uaf access.We found an uaf issue while using stress-ng testing, need to run testcasegetdent and tun in the same time. The steps of the issue is as follows:1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.CPU 0 | CPU 1-------------------------------------------------------------------------traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40338 Severity: Moderate CVSS3 score: 5.2

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: avs: Do not share the name pointer between componentsBy sharing 'name' directly, tearing down components may lead touse-after-free errors. Duplicate the name to avoid that.At the same time, update the order of operations - since commitcee28113db17 ("ASoC: dmaengine_pcm: Allow passing component name viaconfig") the framework does not override component->name if set beforeinvoking the initializer.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2024-2201 Severity: Moderate CVSS3 score: 5.1

Description: A cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38140 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:dm: limit swapping tables for devices with zone write plugsdm_revalidate_zones() only allowed new or previously unzoned devices tocall blk_revalidate_disk_zones(). If the device was already zoned,disk->nr_zones would always equal md->nr_zones, so dm_revalidate_zones()returned without doing any work. This would make the zoned settings forthe device not match the new table. If the device had zone write plugresources, it could run into errors like bdev_zone_is_seq() readinginvalid memory because disk->conv_zones_bitmap was the wrong size.If the device doesn't have any zone write plug resources, callingblk_revalidate_disk_zones() will always correctly update device. Ifblk_revalidate_disk_zones() fails, it can still overwrite or clear thecurrent disk->nr_zones value. In this case, DM must restore the previousvalue of disk->nr_zones, so that the zoned settings will continue tomatch the previous value that it fell back to.If the device already has zone write plug resources,blk_revalidate_disk_zones() will not correctly update them, if it iscalled for arbitrary zoned device changes. Since there is not much needfor this ability, the easiest solution is to disallow any table reloadsthat change the zoned settings, for devices that already have zone plugresources. Specifically, if a device already has zone plug resourcesallocated, it can only switch to another zoned table that also emulateszone append. Also, it cannot change the device size or the zone size. Adevice can switch to an error target.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38493 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:tracing/osnoise: Fix crash in timerlat_dump_stack()We have observed kernel panics when using timerlat with stack saving,with the following dmesg output:memcpy: detected buffer overflow: 88 byte write of buffer size 0WARNING: CPU: 2 PID: 8153 at lib/string_helpers.c:1032 __fortify_report+0x55/0xa0CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x86_64 #1 PREEMPT(lazy)Call Trace: ? trace_buffer_lock_reserve+0x2a/0x60 __fortify_panic+0xd/0xf __timerlat_dump_stack.cold+0xd/0xd timerlat_dump_stack.part.0+0x47/0x80 timerlat_fd_read+0x36d/0x390 vfs_read+0xe2/0x390 ? syscall_exit_to_user_mode+0x1d5/0x210 ksys_read+0x73/0xe0 do_syscall_64+0x7b/0x160 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e__timerlat_dump_stack() constructs the ftrace stack entry like this:struct stack_entry *entry;...memcpy(&entry->caller, fstack->calls, size);entry->size = fstack->nr_entries;Since commit e7186af7fb26 ("tracing: Add back FORTIFY_SOURCE logic tokernel_stack event structure"), struct stack_entry marks its callerfield with __counted_by(size). At the time of the memcpy, entry->sizecontains garbage from the ringbuffer, which under some circumstances iszero, triggering a kernel panic by buffer overflow.Populate the size field before the memcpy so that the out-of-boundscheck knows the correct size. This is analogous to__ftrace_trace_stack().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38658 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet: pci-epf: Do not complete commands twice if nvmet_req_init() failsHave nvmet_req_init() and req->execute() complete failed commands.Description of the problem:nvmet_req_init() calls __nvmet_req_complete() internally upon failure,e.g., unsupported opcode, which calls the "queue_response" callback,this results in nvmet_pci_epf_queue_response() being called, which willcall nvmet_pci_epf_complete_iod() if data_len is 0 or if dma_dir isdifferent from DMA_TO_DEVICE. This results in a double completion asnvmet_pci_epf_exec_iod_work() also calls nvmet_pci_epf_complete_iod()when nvmet_req_init() fails.Steps to reproduce:On the host send a command with an unsupported opcode with nvme-cli,For example the admin command "security receive"$ sudo nvme security-recv /dev/nvme0n1 -n1 -x4096This triggers a double completion as nvmet_req_init() fails andnvmet_pci_epf_queue_response() is called, here iod->dma_dir is stillin the default state of "DMA_NONE" as set by default innvmet_pci_epf_alloc_iod(), so nvmet_pci_epf_complete_iod() is called.Because nvmet_req_init() failed nvmet_pci_epf_complete_iod() is alsocalled in nvmet_pci_epf_exec_iod_work() leading to a double completion.This not only sends two completions to the host but also corrupts thestate of the PCI NVMe target leading to kernel oops.This patch lets nvmet_req_init() and req->execute() complete all failedcommands, and removes the double completion case innvmet_pci_epf_exec_iod_work() therefore fixing the edge cases wheredouble completions occurred.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38699 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Double-free fixWhen the bfad_im_probe() function fails during initialization, the memorypointed to by bfad->im is freed without setting bfad->im to NULL.Subsequently, during driver uninstallation, when the state machine entersthe bfad_sm_stopping state and calls the bfad_im_probe_undo() function,it attempts to free the memory pointed to by bfad->im again, therebytriggering a double-free vulnerability.Set bfad->im to NULL if probing fails.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39760 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:usb: core: config: Prevent OOB read in SS endpoint companion parsingusb_parse_ss_endpoint_companion() checks descriptor type before length,enabling a potentially odd read outside of the buffer size.Fix this up by checking the size first before looking at any of thefields in the descriptor.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40206 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_objref: validate objref and objrefmap expressionsReferencing a synproxy stateful object from OUTPUT hook causes kernelcrash due to infinite recursive calls:BUG: TASK stack guard page was hit at 000000008bda5b8c (stack is 000000003ab1c4a5..00000000494d8b12)[...]Call Trace: __find_rr_leaf+0x99/0x230 fib6_table_lookup+0x13b/0x2d0 ip6_pol_route+0xa4/0x400 fib6_rule_lookup+0x156/0x240 ip6_route_output_flags+0xc6/0x150 __nf_ip6_route+0x23/0x50 synproxy_send_tcp_ipv6+0x106/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 nft_synproxy_do_eval+0x263/0x310 nft_do_chain+0x5a8/0x5f0 [nf_tables nft_do_chain_inet+0x98/0x110 nf_hook_slow+0x43/0xc0 __ip6_local_out+0xf0/0x170 ip6_local_out+0x17/0x70 synproxy_send_tcp_ipv6+0x1a2/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0[...]Implement objref and objrefmap expression validate functions.Currently, only NFT_OBJECT_SYNPROXY object type requires validation.This will also handle a jump to a chain using a synproxy object from theOUTPUT hook.Now when trying to reference a synproxy object in the OUTPUT hook, nftwill produce the following error:synproxy_crash.nft: Error: Could not process rule: Operation not supported synproxy name mysynproxy ^^^^^^^^^^^^^^^^^^^^^^^^

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2026-23104 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix devlink reload call traceCommit 4da71a77fc3b ("ice: read internal temperature sensor") introducedinternal temperature sensor reading via HWMON. ice_hwmon_init() was addedto ice_init_feature() and ice_hwmon_exit() was added to ice_remove(). As aresult if devlink reload is used to reinit the device and then the driveris removed, a call trace can occur.BUG: unable to handle page fault for address: ffffffffc0fd4b5dCall Trace: string+0x48/0xe0 vsnprintf+0x1f9/0x650 sprintf+0x62/0x80 name_show+0x1f/0x30 dev_attr_show+0x19/0x60The call trace repeats approximately every 10 minutes when systemmonitoring tools (e.g., sadc) attempt to read the orphaned hwmon sysfsattributes that reference freed module memory.The sequence is:1. Driver load, ice_hwmon_init() gets called from ice_init_feature()2. Devlink reload down, flow does not call ice_remove()3. Devlink reload up, ice_hwmon_init() gets called from ice_init_feature() resulting in a second instance4. Driver unload, ice_hwmon_exit() called from ice_remove() leaving the first hwmon instance orphaned with dangling pointerFix this by moving ice_hwmon_exit() from ice_remove() toice_deinit_features() to ensure proper cleanup symmetry withice_hwmon_init().

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38491 Severity: Moderate CVSS3 score: 5.0

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: make fallback action and fallback decision atomicSyzkaller reported the following splat: WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 __mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 check_fully_established net/mptcp/options.c:982 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Modules linked in: CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] RIP: 0010:mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] RIP: 0010:check_fully_established net/mptcp/options.c:982 [inline] RIP: 0010:mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00 RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call Trace: tcp_reset+0x26f/0x2b0 net/ipv4/tcp_input.c:4432 tcp_validate_incoming+0x1057/0x1b60 net/ipv4/tcp_input.c:5975 tcp_rcv_established+0x5b5/0x21f0 net/ipv4/tcp_input.c:6166 tcp_v4_do_rcv+0x5dc/0xa70 net/ipv4/tcp_ipv4.c:1925 tcp_v4_rcv+0x3473/0x44a0 net/ipv4/tcp_ipv4.c:2363 ip_protocol_deliver_rcu+0xba/0x480 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2f1/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_local_deliver+0x1be/0x560 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:469 [inline] ip_rcv_finish net/ipv4/ip_input.c:447 [inline] NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_rcv+0x514/0x810 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core+0x197/0x1e0 net/core/dev.c:5975 __netif_receive_skb+0x1f/0x120 net/core/dev.c:6088 process_backlog+0x301/0x1360 net/core/dev.c:6440 __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7453 napi_poll net/core/dev.c:7517 [inline] net_rx_action+0xb44/0x1010 net/core/dev.c:7644 handle_softirqs+0x1d0/0x770 kernel/softirq.c:579 do_softirq+0x3f/0x90 kernel/softirq.c:480 __local_bh_enable_ip+0xed/0x110 kernel/softirq.c:407 local_bh_enable include/linux/bottom_half.h:33 [inline] inet_csk_listen_stop+0x2c5/0x1070 net/ipv4/inet_connection_sock.c:1524 mptcp_check_listen_stop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcp_check_listen_stop net/mptcp/mib.h:118 [inline] __mptcp_close+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcp_close+0x2f/0x140 net/mptcp/protocol.c:3066 inet_release+0xed/0x200 net/ipv4/af_inet.c:435 inet6_release+0x4f/0x70 net/ipv6/af_inet6.c:487 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x402/0xb70 fs/file_table.c:465 task_work_run+0x150/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xd4---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38391 Severity: Moderate CVSS3 score: 4.9

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmodes/displayport: do not index invalid pin_assignmentsA poorly implemented DisplayPort Alt Mode port partner can indicatethat its pin assignment capabilities are greater than the maximumvalue, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_showwill cause a BRK exception due to an out of bounds array access.Prevent for loop in pin_assignment_show from accessinginvalid values in pin_assignments by adding DP_PIN_ASSIGN_MAXvalue in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loopcondition.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-54770 Severity: Moderate CVSS3 score: 4.9

Description: A vulnerability has been identified in the GRUB2 bootloader's network module that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the net_set_vlan command is not properly unregistered when the network module is unloaded from memory. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
grub2 < 2.12-160000.3.1 (version in image is 2.12-160000.2.2).

CVE-2025-54771 Severity: Moderate CVSS3 score: 4.9

Description: A use-after-free vulnerability has been identified in the GNU GRUB (Grand Unified Bootloader). The flaw occurs because the file-closing process incorrectly retains a memory pointer, leaving an invalid reference to a file system structure. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
grub2 < 2.12-160000.3.1 (version in image is 2.12-160000.2.2).

CVE-2025-61662 Severity: Moderate CVSS3 score: 4.9

Description: A Use-After-Free vulnerability has been discovered in GRUB's gettext module. This flaw stems from a programming error where the gettext command remains registered in memory after its module is unloaded. An attacker can exploit this condition by invoking the orphaned command, causing the application to access a memory location that is no longer valid. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
grub2 < 2.12-160000.3.1 (version in image is 2.12-160000.2.2).

CVE-2025-61663 Severity: Moderate CVSS3 score: 4.9

Description: A vulnerability has been identified in the GRUB2 bootloader's normal command that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the normal command is not properly unregistered when the module is unloaded. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability. Impact on the data integrity and confidentiality is also not discarded.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
grub2 < 2.12-160000.3.1 (version in image is 2.12-160000.2.2).

CVE-2025-61664 Severity: Moderate CVSS3 score: 4.9

Description: A vulnerability in the GRUB2 bootloader has been identified in the normal module. This flaw, a memory Use After Free issue, occurs because the normal_exit command is not properly unregistered when its related module is unloaded. An attacker can exploit this condition by invoking the command after the module has been removed, causing the system to improperly access a previously freed memory location. This leads to a system crash or possible impacts in data confidentiality and integrity.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
grub2 < 2.12-160000.3.1 (version in image is 2.12-160000.2.2).

CVE-2025-7039 Severity: Moderate CVSS3 score: 4.9

Description: A flaw was found in glib. An integer overflow during temporary file creation leads to an out-of-bounds memory access, allowing an attacker to potentially perform path traversal or access private temporary file content by creating symbolic links. This vulnerability allows a local attacker to manipulate file paths and access unauthorized data. The core issue stems from insufficient validation of file path lengths during temporary file operations.

Packages affected:

glib2-tools < 2.84.4-160000.1.1 (version in image is 2.84.3-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38120 Severity: Moderate CVSS3 score: 4.8

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_set_pipapo_avx2: fix initial map fillIf the first field doesn't cover the entire start map, then we must zeroout the remainder, else we leak those bits into the next match round map.The early fix was incomplete and did only fix up the generic Cimplementation.A followup patch adds a test case to nft_concat_range.sh.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-4373 Severity: Moderate CVSS3 score: 4.8

Description: A flaw was found in GLib, which is vulnerable to an integer overflow in the g_string_insert_unichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
glib2-tools > 0-0 (version in image is 2.84.3-160000.2.2).

CVE-2025-61661 Severity: Moderate CVSS3 score: 4.8

Description: A vulnerability has been identified in the GRUB (Grand Unified Bootloader) component. This flaw occurs because the bootloader mishandles string conversion when reading information from a USB device, allowing an attacker to exploit inconsistent length values. A local attacker can connect a maliciously configured USB device during the boot sequence to trigger this issue. A successful exploitation may lead GRUB to crash, leading to a Denial of Service. Data corruption may be also possible, although given the complexity of the exploit the impact is most likely limited.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
grub2 < 2.12-160000.3.1 (version in image is 2.12-160000.2.2).

CVE-2023-54013 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:interconnect: Fix locking for runpm vs reclaimFor cases where icc_bw_set() can be called in callbaths that coulddeadlock against shrinker/reclaim, such as runpm resume, we need todecouple the icc locking. Introduce a new icc_bw_lock for cases wherewe need to serialize bw aggregation and update to decouple that frompaths that require memory allocation such as node/link creation/destruction.Fixes this lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.2.0-rc8-debug+ #554 Not tainted ------------------------------------------------------ ring0/132 is trying to acquire lock: ffffff80871916d0 (&gmu->lock){+.+.}-{3:3}, at: a6xx_pm_resume+0xf0/0x234 but task is already holding lock: ffffffdb5aee57e8 (dma_fence_map){++++}-{0:0}, at: msm_job_run+0x68/0x150 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (dma_fence_map){++++}-{0:0}: __dma_fence_might_wait+0x74/0xc0 dma_resv_lockdep+0x1f4/0x2f4 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x80/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 topology_parse_cpu_capacity+0x8c/0x178 get_cpu_for_node+0x88/0xc4 parse_cluster+0x1b0/0x28c parse_cluster+0x8c/0x28c init_cpu_topology+0x168/0x188 smp_prepare_cpus+0x24/0xf8 kernel_init_freeable+0x18c/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #2 (fs_reclaim){+.+.}-{0:0}: __fs_reclaim_acquire+0x3c/0x48 fs_reclaim_acquire+0x54/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 kzalloc.constprop.0+0x14/0x20 icc_node_create_nolock+0x4c/0xc4 icc_node_create+0x38/0x58 qcom_icc_rpmh_probe+0x1b8/0x248 platform_probe+0x70/0xc4 really_probe+0x158/0x290 __driver_probe_device+0xc8/0xe0 driver_probe_device+0x44/0x100 __driver_attach+0xf8/0x108 bus_for_each_dev+0x78/0xc4 driver_attach+0x2c/0x38 bus_add_driver+0xd0/0x1d8 driver_register+0xbc/0xf8 __platform_driver_register+0x30/0x3c qnoc_driver_init+0x24/0x30 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #1 (icc_lock){+.+.}-{3:3}: __mutex_lock+0xcc/0x3c8 mutex_lock_nested+0x30/0x44 icc_set_bw+0x88/0x2b4 _set_opp_bw+0x8c/0xd8 _set_opp+0x19c/0x300 dev_pm_opp_set_opp+0x84/0x94 a6xx_gmu_resume+0x18c/0x804 a6xx_pm_resume+0xf8/0x234 adreno_runtime_resume+0x2c/0x38 pm_generic_runtime_resume+0x30/0x44 __rpm_callback+0x15c/0x174 rpm_callback+0x78/0x7c rpm_resume+0x318/0x524 __pm_runtime_resume+0x78/0xbc adreno_load_gpu+0xc4/0x17c msm_open+0x50/0x120 drm_file_alloc+0x17c/0x228 drm_open_helper+0x74/0x118 drm_open+0xa0/0x144 drm_stub_open+0xd4/0xe4 chrdev_open+0x1b8/0x1e4 do_dentry_open+0x2f8/0x38c vfs_open+0x34/0x40 path_openat+0x64c/0x7b4 do_filp_open+0x54/0xc4 do_sys_openat2+0x9c/0x100 do_sys_open+0x50/0x7c __arm64_sys_openat+0x28/0x34 invoke_syscall+0x8c/0x128 el0_svc_common.constprop.0+0xa0/0x11c do_el0_---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-13978 Severity: Moderate CVSS3 score: 4.7

Description: A vulnerability was found in LibTIFF up to 4.7.0. It has been declared as problematic. Affected by this vulnerability is the function t2p_read_tiff_init of the file tools/tiff2pdf.c of the component fax2ps. The manipulation leads to null pointer dereference. The attack needs to be approached locally. The complexity of an attack is rather high. The exploitation appears to be difficult. The patch is named 2ebfffb0e8836bfb1cd7d85c059cd285c59761a4. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libtiff6 < 4.7.1-160000.1.1 (version in image is 4.7.0-160000.2.2).

CVE-2024-50138 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Use raw_spinlock_t in ringbufThe function __bpf_ringbuf_reserve is invoked from a tracepoint, whichdisables preemption. Using spinlock_t in this context can lead to a"sleep in atomic" warning in the RT variant. This issue is illustratedin the example below:BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progspreempt_count: 1, expected: 0RCU nest depth: 1, expected: 1INFO: lockdep is turned off.Preemption disabled at:[] migrate_enable+0xc0/0x39cCPU: 7 PID: 556208 Comm: test_progs Tainted: GHardware name: Qualcomm SA8775P Ride (DT)Call trace: dump_backtrace+0xac/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0xac/0xe8 dump_stack+0x18/0x30 __might_resched+0x3bc/0x4fc rt_spin_lock+0x8c/0x1a4 __bpf_ringbuf_reserve+0xc4/0x254 bpf_ringbuf_reserve_dynptr+0x5c/0xdc bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238 trace_call_bpf+0x238/0x774 perf_call_bpf_enter.isra.0+0x104/0x194 perf_syscall_enter+0x2f8/0x510 trace_sys_enter+0x39c/0x564 syscall_trace_enter+0x220/0x3c0 do_el0_svc+0x138/0x1dc el0_svc+0x54/0x130 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180Switch the spinlock to raw_spinlock_t to avoid this error.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-50145 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()build_skb() returns NULL in case of a memory allocation failure so handleit inside __octep_oq_process_rx() to avoid NULL pointer dereference.__octep_oq_process_rx() is called during NAPI polling by the driver. Ifskb allocation fails, keep on pulling packets out of the Rx DMA queue: weshouldn't break the polling immediately and thus falsely indicate to theoctep_napi_poll() that the Rx pressure is going down. As there is noassociated skb in this case, don't process the packets and don't push themup the network stack - they are skipped.Helper function is implemented to unmmap/flush all the fragment buffersused by the dropped packet. 'alloc_failures' counter is incremented tomark the skb allocation error in driver statistics.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-50163 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Make sure internal and UAPI bpf_redirect flags don't overlapThe bpf_redirect_info is shared between the SKB and XDP redirect paths,and the two paths use the same numeric flag values in the ri->flagsfield (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means thatif skb bpf_redirect_neigh() is used with a non-NULL params argument and,subsequently, an XDP redirect is performed using the samebpf_redirect_info struct, the XDP path will get confused and end upcrashing, which syzbot managed to trigger.With the stack-allocated bpf_redirect_info, the structure is no longershared between the SKB and XDP paths, so the crash doesn't happenanymore. However, different code paths using identically-numbered flagvalues in the same struct field still seems like a bit of a mess, sothis patch cleans that up by moving the flag definitions together andredefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlapwith the flags used for XDP. It also adds a BUILD_BUG_ON() check to makesure the overlap is not re-introduced by mistake.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-56738 Severity: Moderate CVSS3 score: 4.7

Description: GNU GRUB (aka GRUB2) through 2.12 does not use a constant-time algorithm for grub_crypto_memcmp and thus allows side-channel attacks.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
grub2 < 2.12-160000.3.1 (version in image is 2.12-160000.2.2).

CVE-2025-37856 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: harden block_group::bg_list against list_del() racesAs far as I can tell, these calls of list_del_init() on bg_list cannotrun concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),as they are in transaction error paths and situations where the blockgroup 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 derefearly and the real final deref underflows the refcount, resulting in a WARNING.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38019 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_router: Fix use-after-free when deleting GRE net devicesThe driver only offloads neighbors that are constructed on top of netdevices registered by it or their uppers (which are all Ethernet). Thedevice supports GRE encapsulation and decapsulation of forwardedtraffic, but the driver will not offload dummy neighbors constructed ontop of GRE net devices as they are not uppers of its net devices: # ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1 # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 NOARP(Note that the neighbor is not marked with 'offload')When the driver is reloaded and the existing configuration is replayed,the driver does not perform the same check regarding existing neighborsand offloads the previously added one: # devlink dev reload pci/0000:01:00.0 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 offload NOARPIf the neighbor is later deleted, the driver will ignore thenotification (given the GRE net device is not its upper) and willtherefore keep referencing freed memory, resulting in a use-after-free[1] when the net device is deleted: # ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1 # ip link del dev gre1Fix by skipping neighbor replay if the net device for which the replayis performed is not our upper.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200Read of size 8 at addr ffff888155b0e420 by task ip/2282[...]Call Trace: dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6f/0x350 print_report+0x108/0x205 kasan_report+0xdf/0x110 mlxsw_sp_neigh_entry_update+0x1ea/0x200 mlxsw_sp_router_rif_gone_sync+0x2a8/0x440 mlxsw_sp_rif_destroy+0x1e9/0x750 mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0 mlxsw_sp_router_netdevice_event+0x3ac/0x15e0 notifier_call_chain+0xca/0x150 call_netdevice_notifiers_info+0x7f/0x100 unregister_netdevice_many_notify+0xc8c/0x1d90 rtnl_dellink+0x34e/0xa50 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38093 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: dts: qcom: x1e80100: Add GPU coolingUnlike the CPU, the GPU does not throttle its speed automatically when itreaches high temperatures. With certain high GPU loads it is possible toreach the critical hardware shutdown temperature of 120?C, endangering thehardware and making it impossible to run certain applications.Set up GPU cooling similar to the ACPI tables, by throttling the GPU speedwhen reaching 95?C and polling every 200ms.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38102 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notifyDuring our test, it is found that a warning can be trigger in try_grab_folioas 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: 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_fastand can be seen in vmci_ctx_unset_notify which will try to put_page. Howeverget_user_pages_fast is not finished here and lead to followingtry_grab_folio warning. The race condition is shown as follow:cpu0 cpu1vmci_host_do_set_notifyvmci_host_setup_notifyget_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);lockless_pages_from_mmgup_pgd_rangegup_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_pagesfollow_trans_huge_pmdtry_grab_folio // warn hereTo slove this, use local variable page to make notify_page can be seenafter finish get_user_pages_fast.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38107 Severity: Moderate CVSS3 score: 4.7

Description: 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 timerfires 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 qdiscbefore releasing the lock.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38108 Severity: Moderate CVSS3 score: 4.7

Description: 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 timerfires 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 qdiscbefore releasing the lock.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38112 Severity: Moderate CVSS3 score: 4.7

Description: 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 residesin a sockmap. After the last sk_psock_put() (which usually happens whensocket is removed from sockmap), sk->sk_prot gets restored andsk->sk_prot->sock_is_readable becomes NULL.This makes sk_is_readable() racy, if the value of sk->sk_prot is reloadedafter the initial check. Which in turn may lead to a null pointerdereference.Ensure the function pointer does not turn NULL after the check.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38114 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:e1000: Move cancel_work_sync to avoid deadlockPreviously, e1000_down called cancel_work_sync for the e1000 reset task(via e1000_down_and_stop), which takes RTNL.As reported by users and syzbot, a deadlock is possible in the followingscenario:CPU 0: - RTNL is held - e1000_close - e1000_down - cancel_work_sync (cancel / wait for e1000_reset_task())CPU 1: - process_one_work - e1000_reset_task - take RTNLTo remedy this, avoid calling cancel_work_sync from e1000_down(e1000_reset_task does nothing if the device is down anyway). Instead,call cancel_work_sync for e1000_reset_task when the device is beingremoved.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38125 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: make sure that ptp_rate is not 0 before configuring ESTIf the ptp_rate recorded earlier in the driver happens to be 0, thisbogus value will propagate up to EST configuration, where it willtrigger a division by 0.Prevent this division by 0 by adding the corresponding check and errorcode.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38174 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:thunderbolt: Do not double dequeue a configuration requestSome 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: ? 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/0x30The circumstances are unclear, however, the theory is thattb_cfg_request_work() can be scheduled twice for a request:first time via frame.callback from ring_work() and secondtime from tb_cfg_request(). Both times kworkers will executetb_cfg_request_dequeue(), which results in double list_del()from the ctl->request_queue (the list poison deference hintsat it: 0xdead000000000122).Do not dequeue requests that don't have TB_CFG_REQUEST_ACTIVEbit set.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38231 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: Initialize ssc before laundromat_work to prevent NULL dereferenceIn nfs4_state_start_net(), laundromat_work may access nfsd_ssc throughnfs4_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 fornfsd_ssc initialization to complete. However, when the kernel waits toolong 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), thedelayed work may start before nfsd_ssc initialization finishes.Fix this by moving nfsd_ssc initialization before starting laundromat_work.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38234 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:sched/rt: Fix race in push_rt_taskOverview========When a CPU chooses to call push_rt_task and picks a task to push toanother CPU's runqueue then it will call find_lock_lowest_rq methodwhich would take a double lock on both CPUs' runqueues. If one of thelocks aren't readily available, it may lead to dropping the currentrunqueue lock and reacquiring both the locks at once. During this windowit is possible that the task is already migrated and is running on someother CPU. These cases are already handled. However, if the task ismigrated and has already been executed and another CPU is now trying towake it up (ttwu) such that it is queued again on the runqeue(on_rq is 1) and also if the task was run by the same CPU, then thecurrent checks will pass even though the task was migrated out and is nolonger in the pushable tasks list.Crashes=======This bug resulted in quite a few flavors of crashes triggering kernelpanics with various crash signatures such as assert failures, pagefaults, null pointer dereferences, and queue corruption errors allcoming from scheduler itself.Some of the crashes:-> kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx >= MAX_RT_PRIO) Call Trace: ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0x85/0x100 ? pick_next_task_rt+0x6e/0x1d0 ? do_error_trap+0x64/0xa0 ? pick_next_task_rt+0x6e/0x1d0 ? exc_invalid_op+0x4c/0x60 ? pick_next_task_rt+0x6e/0x1d0 ? asm_exc_invalid_op+0x12/0x20 ? pick_next_task_rt+0x6e/0x1d0 __schedule+0x5cb/0x790 ? update_ts_time_stats+0x55/0x70 schedule_idle+0x1e/0x40 do_idle+0x15e/0x200 cpu_startup_entry+0x19/0x20 start_secondary+0x117/0x160 secondary_startup_64_no_verify+0xb0/0xbb-> BUG: kernel NULL pointer dereference, address: 00000000000000c0 Call Trace: ? __die_body+0x1a/0x60 ? no_context+0x183/0x350 ? __warn+0x8a/0xe0 ? exc_page_fault+0x3d6/0x520 ? asm_exc_page_fault+0x1e/0x30 ? pick_next_task_rt+0xb5/0x1d0 ? pick_next_task_rt+0x8c/0x1d0 __schedule+0x583/0x7e0 ? update_ts_time_stats+0x55/0x70 schedule_idle+0x1e/0x40 do_idle+0x15e/0x200 cpu_startup_entry+0x19/0x20 start_secondary+0x117/0x160 secondary_startup_64_no_verify+0xb0/0xbb-> BUG: unable to handle page fault for address: ffff9464daea5900 kernel BUG at kernel/sched/rt.c:1861! BUG_ON(rq->cpu != task_cpu(p))-> kernel BUG at kernel/sched/rt.c:1055! BUG_ON(!rq->nr_running) Call Trace: ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0x85/0x100 ? dequeue_top_rt_rq+0xa2/0xb0 ? do_error_trap+0x64/0xa0 ? dequeue_top_rt_rq+0xa2/0xb0 ? exc_invalid_op+0x4c/0x60 ? dequeue_top_rt_rq+0xa2/0xb0 ? asm_exc_invalid_op+0x12/0x20 ? dequeue_top_rt_rq+0xa2/0xb0 dequeue_rt_entity+0x1f/0x70 dequeue_task_rt+0x2d/0x70 __schedule+0x1a8/0x7e0 ? blk_finish_plug+0x25/0x40 schedule+0x3c/0xb0 futex_wait_queue_me+0xb6/0x120 futex_wait+0xd9/0x240 do_futex+0x344/0xa90 ? get_mm_exe_file+0x30/0x60 ? audit_exe_compare+0x58/0x70 ? audit_filter_rules.constprop.26+0x65e/0x1220 __x64_sys_futex+0x148/0x1f0 do_syscall_64+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x62/0xc7-> BUG: unable to handle page fault for address: ffff8cf3608bc2c0 Call Trace: ? __die_body+0x1a/0x60 ? no_context+0x183/0x350 ? spurious_kernel_fault+0x171/0x1c0 ? exc_page_fault+0x3b6/0x520 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? asm_exc_page_fault+0x1e/0x30 ? _cond_resched+0x15/0x30 ? futex_wait_queue_me+0xc8/0x120 ? futex_wait+0xd9/0x240 ? try_to_wake_up+0x1b8/0x490 ? futex_wake+0x78/0x160 ? do_futex+0xcd/0xa90 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? plist_del+0x6a/0xd0 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? dequeue_pushable_task+0x20/0x70 ? __schedule+0x382/0x7e0 ? asm_sysvec_reschedule_i---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38244 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential deadlock when reconnecting channelsFix cifs_signal_cifsd_for_reconnect() to take the correct lock orderand prevent the following deadlock from happening======================================================WARNING: possible circular locking dependency detected6.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/0x200but task is already holding lock:ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200which 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/0x30other 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38245 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().syzbot reported a warning below during atm_dev_register(). [0]Before creating a new device and procfs/sysfs for it, atm_dev_register()looks up a duplicated device by __atm_dev_lookup(). These operations aredone under atm_dev_mutex.However, when removing a device in atm_dev_deregister(), it releases themutex just after removing the device from the list that __atm_dev_lookup()iterates over.So, there will be a small race window where the device does not exist onthe device list but procfs/sysfs are still not removed, triggering thesplat.Let's hold the mutex until procfs/sysfs are removed inatm_dev_deregister().[0]:proc_dir_entry 'atm/atmtcp:0' already registeredWARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377Modules linked in:CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: proc_create_data+0xbe/0x110 fs/proc/generic.c:585 atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361 atm_dev_register+0x46d/0x890 net/atm/resources.c:113 atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369 atmtcp_attach drivers/atm/atmtcp.c:403 [inline] atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x115/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f38b3b74459Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702fR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0acR13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38253 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:HID: wacom: fix crash in wacom_aes_battery_handler()Commit fd2a9b29dc9c ("HID: wacom: Remove AES power_supply after extendedinactivity") introduced wacom_aes_battery_handler() which is scheduledas a delayed work (aes_battery_work).In wacom_remove(), aes_battery_work is not canceled. Consequently, ifthe device is removed while aes_battery_work is still pending, then hardcrashes or "Oops: general protection fault..." are experienced whenwacom_aes_battery_handler() is finally called. E.g., this happens withbuilt-in USB devices after resume from hibernate when aes_battery_workwas still pending at the time of hibernation.So, take care to cancel aes_battery_work in wacom_remove().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38268 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: tcpm: move tcpm_queue_vdm_unlocked to asynchronous workA state check was previously added to tcpm_queue_vdm_unlocked toprevent a deadlock where the DisplayPort Alt Mode driver would beexecuting work and attempting to grab the tcpm_lock while the TCPMwas holding the lock and attempting to unregister the altmode, blockingon the altmode driver's cancel_work_sync call.Because the state check isn't protected, there is a small windowwhere the Alt Mode driver could determine that the TCPM isin a ready state and attempt to grab the lock while theTCPM grabs the lock and changes the TCPM state to one thatcauses the deadlock. The callstack is provided below:[110121.667392][ C7] Call trace:[110121.667396][ C7] __switch_to+0x174/0x338[110121.667406][ C7] __schedule+0x608/0x9f0[110121.667414][ C7] schedule+0x7c/0xe8[110121.667423][ C7] kernfs_drain+0xb0/0x114[110121.667431][ C7] __kernfs_remove+0x16c/0x20c[110121.667436][ C7] kernfs_remove_by_name_ns+0x74/0xe8[110121.667442][ C7] sysfs_remove_group+0x84/0xe8[110121.667450][ C7] sysfs_remove_groups+0x34/0x58[110121.667458][ C7] device_remove_groups+0x10/0x20[110121.667464][ C7] device_release_driver_internal+0x164/0x2e4[110121.667475][ C7] device_release_driver+0x18/0x28[110121.667484][ C7] bus_remove_device+0xec/0x118[110121.667491][ C7] device_del+0x1e8/0x4ac[110121.667498][ C7] device_unregister+0x18/0x38[110121.667504][ C7] typec_unregister_altmode+0x30/0x44[110121.667515][ C7] tcpm_reset_port+0xac/0x370[110121.667523][ C7] tcpm_snk_detach+0x84/0xb8[110121.667529][ C7] run_state_machine+0x4c0/0x1b68[110121.667536][ C7] tcpm_state_machine_work+0x94/0xe4[110121.667544][ C7] kthread_worker_fn+0x10c/0x244[110121.667552][ C7] kthread+0x104/0x1d4[110121.667557][ C7] ret_from_fork+0x10/0x20[110121.667689][ C7] Workqueue: events dp_altmode_work[110121.667697][ C7] Call trace:[110121.667701][ C7] __switch_to+0x174/0x338[110121.667710][ C7] __schedule+0x608/0x9f0[110121.667717][ C7] schedule+0x7c/0xe8[110121.667725][ C7] schedule_preempt_disabled+0x24/0x40[110121.667733][ C7] __mutex_lock+0x408/0xdac[110121.667741][ C7] __mutex_lock_slowpath+0x14/0x24[110121.667748][ C7] mutex_lock+0x40/0xec[110121.667757][ C7] tcpm_altmode_enter+0x78/0xb4[110121.667764][ C7] typec_altmode_enter+0xdc/0x10c[110121.667769][ C7] dp_altmode_work+0x68/0x164[110121.667775][ C7] process_one_work+0x1e4/0x43c[110121.667783][ C7] worker_thread+0x25c/0x430[110121.667789][ C7] kthread+0x104/0x1d4[110121.667794][ C7] ret_from_fork+0x10/0x20Change tcpm_queue_vdm_unlocked to queue for tcpm_queue_vdm_work,which can perform the state check while holding the TCPM lockwhile the Alt Mode lock is no longer held. This requires a newstruct to hold the vdm data, altmode_vdm_event.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38290 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: fix node corruption in ar->arvifs listIn current WLAN recovery code flow, ath12k_core_halt() only reinitializesthe "arvifs" list head. This will cause the list node immediately followingthe list head to become an invalid list node. Because the prev of that nodestill 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 ithappens before the spin_lock_bh(&ar->data_lock) inath12k_mac_vdev_delete(), list_del() will detect the previously mentionedsituation, 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 nodesvalid, ensuring that the list_del() in ath12k_mac_vdev_delete() can executenormally.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/0x100process_one_work+0x164/0x2d0worker_thread+0x254/0x380kthread+0xfc/0x100ret_from_fork+0x10/0x20The 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38293 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix node corruption in ar->arvifs listIn current WLAN recovery code flow, ath11k_core_halt() onlyreinitializes the "arvifs" list head. This will cause thelist node immediately following the list head to become aninvalid list node. Because the prev of that node still pointsto 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 vifremoval, and it happens before the spin_lock_bh(&ar->data_lock)in ath11k_mac_op_remove_interface(), list_del() will detect thepreviously mentioned situation, thereby triggering a kernel panic.The fix is to remove and reinitialize all vif list nodes from thelist head "arvifs" during WLAN halt. The reinitialization is to makethe list nodes valid, ensuring that the list_del() inath11k_mac_op_remove_interface() can execute normally.Call trace:__list_del_entry_valid_or_report+0xb8/0xd0ath11k_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/0x234dev_change_flags+0x24/0x6cdevinet_ioctl+0x3a0/0x670inet_ioctl+0x200/0x248sock_do_ioctl+0x60/0x118sock_ioctl+0x274/0x35c__arm64_sys_ioctl+0xac/0xf0invoke_syscall+0x48/0x114...Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38302 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:block: don't use submit_bio_noacct_nocheck in blk_zone_wplug_bio_workBios queued up in the zone write plug have already gone through all allpreparation in the submit_bio path, including the freeze protection.Submitting them through submit_bio_noacct_nocheck duplicates the workand can can cause deadlocks when freezing a queue with pending biowrite plugs.Go straight to ->submit_bio or blk_mq_submit_bio to bypass thesuperfluous extra freeze protection and checks.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38306 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:fs/fhandle.c: fix a race in call of has_locked_children()may_decode_fh() is calling has_locked_children() while holding no locks.That's an oopsable race...The rest of the callers are safe since they are holding namespace_sem andare guaranteed a positive refcount on the mount in question.Rename the current has_locked_children() to __has_locked_children(), makeit static and switch the fs/namespace.c users to it.Make has_locked_children() a wrapper for __has_locked_children(), callingthe latter under read_seqlock_excl(&mount_lock).

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38311 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:iavf: get rid of the crit lockGet rid of the crit lock.That frees us from the error prone logic of try_locks.Thanks to netdev_lock() by Jakub it is now easy, and in most cases we wereprotected by it already - replace crit lock by netdev lock when it was notthe case.Lockdep reports that we should cancel the work under crit_lock [splat1],and that was the scheme we have mostly followed since [1] by Slawomir.But when that is done we still got into deadlocks [splat2]. So insteadwe should look at the bigger problem, namely "weird locking/scheduling"of the iavf. The first step to fix that is to remove the crit lock.I will followup with a -next series that simplifies scheduling/tasks.Cancel the work without netdev lock (weird unlock+lock scheme),to fix the [splat2] (which would be totally ugly if we would keptthe crit lock).Extend protected part of iavf_watchdog_task() to include schedulingmore work.Note that the removed comment in iavf_reset_task() was misplaced,it belonged to inside of the removed if condition, so it's gone now.[splat1] - w/o this patch - The deadlock during VF removal: WARNING: possible circular locking dependency detected sh/3825 is trying to acquire lock: ((work_completion)(&(&adapter->watchdog_task)->work)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470 but task is already holding lock: (&adapter->crit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf] which lock already depends on the new lock.[splat2] - when cancelling work under crit lock, w/o this series, see [2] for the band aid attempt WARNING: possible circular locking dependency detected sh/3550 is trying to acquire lock: ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 but task is already holding lock: (&dev->lock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf] which lock already depends on the new lock.[1] fc2e6b3b132a ("iavf: Rework mutexes for better synchronisation")[2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38354 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/gpu: Fix crash when throttling GPU immediately during bootThere is a small chance that the GPU is already hot during boot. In thatcase, the call to of_devfreq_cooling_register() will immediately try toapply 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 readthe GMU registers inside a6xx_gpu_busy(). A similar issue was fixed beforein commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), butunlike msm_devfreq_suspend(), it doesn't set the df->suspended flagaccordingly. This means the df->suspended flag does not match the actualdevfreq state after initialization and msm_devfreq_get_dev_status() willend up accessing GMU registers, causing the crash.Fix this by setting df->suspended correctly during initialization.Patchwork: https://patchwork.freedesktop.org/patch/650772/

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38355 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: Process deferred GGTT node removals on device unwindWhile we are indirectly draining our dedicated workqueue ggtt->wqthat we use to complete asynchronous removal of some GGTT nodes,this happends as part of the managed-drm unwinding (ggtt_fini_early),which could be later then manage-device unwinding, where we couldalready unmap our MMIO/GMS mapping (mmio_fini).This was recently observed during unsuccessful VF initialization: [ ] xe 0000:00:02.1: probe with driver xe failed with error -62 [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747340 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747540 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747240 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747040 tiles_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746840 mmio_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747f40 xe_bo_pinned_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746b40 devm_drm_dev_init_release (16 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] drmres release begin [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef81640 __fini_relay (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80d40 guc_ct_fini (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80040 __drmm_mutex_release (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80140 ggtt_fini_early (8 bytes)and this was leading to: [ ] BUG: unable to handle page fault for address: ffffc900058162a0 [ ] #PF: supervisor write access in kernel mode [ ] #PF: error_code(0x0002) - not-present page [ ] Oops: Oops: 0002 [#1] SMP NOPTI [ ] Tainted: [W]=WARN [ ] Workqueue: xe-ggtt-wq ggtt_node_remove_work_func [xe] [ ] RIP: 0010:xe_ggtt_set_pte+0x6d/0x350 [xe] [ ] Call Trace: [ ] [ ] xe_ggtt_clear+0xb0/0x270 [xe] [ ] ggtt_node_remove+0xbb/0x120 [xe] [ ] ggtt_node_remove_work_func+0x30/0x50 [xe] [ ] process_one_work+0x22b/0x6f0 [ ] worker_thread+0x1e8/0x3dAdd managed-device action that will explicitly drain the workqueuewith all pending node removals prior to releasing MMIO/GSM mapping.(cherry picked from commit 89d2835c3680ab1938e22ad81b1c9f8c686bd391)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38373 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:IB/mlx5: Fix potential deadlock in MR deregistrationThe issue arises when kzalloc() is invoked while holding umem_mutex orany other lock acquired under umem_mutex. This is problematic becausekzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invokemmu_notifier_invalidate_range_start(). This function can lead tomlx5_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 withincache_ent_find_and_store(), we encounter the same deadlock due tore-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 holdumem_mutex while performing memory allocations that could triggerthe reclaim path.This change prevents the deadlock by ensuring proper lock ordering andavoiding holding locks during memory allocation operations that couldtrigger 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---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38383 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc: fix data race in show_numa_info()The following data-race was found in show_numa_info():==================================================================BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_showread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....value changed: 0x0000008f -> 0x00000000==================================================================According to this report,there is a read/write data-race becausem->private is accessible to multiple CPUs. To fix this, instead ofallocating the heap in proc_vmalloc_init() and passing the heap address tom->private, vmalloc_info_show() should allocate the heap.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38387 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Initialize obj_event->obj_sub_list before xa_insertThe obj_event may be loaded immediately after inserted, then if thelist_head is not initialized then we may get a poisonous pointer. Thisfixes 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 ...

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38393 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAINWe found a few different systems hung up in writeback waiting on the samepage lock, and one task waiting on the NFS_LAYOUT_DRAIN bit inpnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding countwas zero.It seems most likely that this is another race between the waiter and wakersimilar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task").Fix it up by applying the advised barrier.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38404 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: displayport: Fix potential deadlockThe 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 mutex2. typec_altmode_vdm() -> dp_altmode_vdm() ->3. typec_altmode_exit() -> cros_typec_altmode_exit()4. cros_typec_altmode_exit() attempts to acquire the mutex againTo prevent this, defer the `typec_altmode_exit()` call by schedulingit rather than calling it directly from within the mutex-protectedcontext.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38428 Severity: Moderate CVSS3 score: 4.7

Description: 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 dotrust 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);"

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38436 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/scheduler: signal scheduled fence when kill jobWhen an entity from application B is killed, drm_sched_entity_kill()removes all jobs belonging to that entity throughdrm_sched_entity_kill_jobs_work(). If application A's job depends on ascheduled fence from application B's job, and that fence is not properlysignaled during the killing process, application A's dependency cannot becleared.This leads to application A hanging indefinitely while waiting for adependency that will never be resolved. Fix this issue by ensuring thatscheduled fences are properly signaled when an entity is killed, allowingdependent applications to continue execution.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38440 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix race between DIM disable and net_dim()There's a race between disabling DIM and NAPI callbacks using the dimpointer on the RQ or SQ.If NAPI checks the DIM state bit and sees it still set, it assumes`rq->dim` or `sq->dim` is valid. But if DIM gets disabled right afterthat check, the pointer might already be set to NULL, leading to a NULLpointer dereference in net_dim().Fix this by calling `synchronize_net()` before freeing the DIM context.This ensures all in-progress NAPI callbacks are finished before thepointer is cleared.Kernel log:BUG: kernel NULL pointer dereference, address: 0000000000000000...RIP: 0010:net_dim+0x23/0x190...Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? common_interrupt+0xf/0xa0 ? sysvec_call_function_single+0xb/0x90 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? net_dim+0x23/0x190 ? mlx5e_poll_ico_cq+0x41/0x6f0 [mlx5_core] ? sysvec_apic_timer_interrupt+0xb/0x90 mlx5e_handle_rx_dim+0x92/0xd0 [mlx5_core] mlx5e_napi_poll+0x2cd/0xac0 [mlx5_core] ? mlx5e_poll_ico_cq+0xe5/0x6f0 [mlx5_core] busy_poll_stop+0xa2/0x200 ? mlx5e_napi_poll+0x1d9/0xac0 [mlx5_core] ? mlx5e_trigger_irq+0x130/0x130 [mlx5_core] __napi_busy_loop+0x345/0x3b0 ? sysvec_call_function_single+0xb/0x90 ? asm_sysvec_call_function_single+0x16/0x20 ? sysvec_apic_timer_interrupt+0xb/0x90 ? pcpu_free_area+0x1e4/0x2e0 napi_busy_loop+0x11/0x20 xsk_recvmsg+0x10c/0x130 sock_recvmsg+0x44/0x70 __sys_recvfrom+0xbc/0x130 ? __schedule+0x398/0x890 __x64_sys_recvfrom+0x20/0x30 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53...---[ end trace 0000000000000000 ]---...---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38460 Severity: Moderate CVSS3 score: 4.7

Description: 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]: clipcauses 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 into_atmarpd().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38461 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Fix transport_* TOCTOUTransport assignment may race with module unload. Protect new_transportfrom 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: fffffbfff8056000Oops: Oops: 0000 [#1] SMP KASANRIP: 0010:vsock_assign_transport+0x366/0x600Call 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38467 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/exynos: exynos7_drm_decon: add vblank check in IRQ handlingIf there's support for another console device (such as a TTY serial),the kernel occasionally panics during boot. The panic message and arelevant 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 sortof race condition.Add a check to validate if the drm device can handle vblanks beforecalling drm_crtc_handle_vblank() to avoid this.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38472 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack: fix crash due to removal of uninitialised entryA crash in conntrack was reported while trying to unlink the conntrackentry from the hash bucket list: [exception RIP: __nf_ct_delete_from_lists+172] [..] #7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack] #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack] #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack] [..]The nf_conn struct is marked as allocated from slab but appears to be ina partially initialised state: ct hlist pointer is garbage; looks like the ct hash value (hence crash). ct->status is equal to IPS_CONFIRMED|IPS_DYING, which is expected ct->timeout is 30000 (=30s), which is unexpected.Everything else looks like normal udp conntrack entry. If we ignorect->status and pretend its 0, the entry matches those that are newlyallocated but not yet inserted into the hash: - ct hlist pointers are overloaded and store/cache the raw tuple hash - ct->timeout matches the relative time expected for a new udp flow rather than the absolute 'jiffies' value.If it were not for the presence of IPS_CONFIRMED,__nf_conntrack_find_get() would have skipped the entry.Theory is that we did hit following race:cpu x cpu y cpu z found entry E found entry E E is expired nf_ct_delete() return E to rcu slab init_conntrack E is re-inited, ct->status set to 0 reply tuplehash hnnode.pprev stores hash value.cpu y found E right before it was deleted on cpu x.E is now re-inited on cpu z. cpu y was preempted beforechecking for expiry and/or confirm bit. ->refcnt set to 1 E now owned by skb ->timeout set to 30000If cpu y were to resume now, it would observe E asexpired but would skip E due to missing CONFIRMED bit. nf_conntrack_confirm gets called sets: ct->status |= CONFIRMED This is wrong: E is not yet added to hashtable.cpu y resumes, it observes E as expired but CONFIRMED: nf_ct_expired() -> yes (ct->timeout is 30s) confirmed bit set.cpu y will try to delete E from the hashtable: nf_ct_delete() -> set DYING bit __nf_ct_delete_from_listsEven this scenario doesn't guarantee a crash:cpu z still holds the table bucket lock(s) so y blocks: wait for spinlock held by z CONFIRMED is set but there is no guarantee ct will be added to hash: "chaintoolong" or "clash resolution" logic both skip the insert step. reply hnnode.pprev still stores the hash value. unlocks spinlock return NF_DROP In case CPU z does insert the entry into the hashtable, cpu y will unlinkE again right away but no crash occurs.Without 'cpu y' race, 'garbage' hlist is of no consequence:ct refcnt remains at 1, eventually skb will be free'd and E getsdestroyed via: nf_conntrack_put -> nf_conntrack_destroy -> nf_ct_destroy.To resolve this, move the IPS_CONFIRMED assignment after the tableinsertion but before the unlock.Pablo points out that the confirm-bit-store could be reordered to happenbefore hlist add resp. the timeout fixup, so switch to set_bit andbefore_atomic memory barrier to prevent this.It doesn't matter if other CPUs can observe a newly inserted entry rightbefore the CONFIRMED bit was set:Such event cannot be distinguished from above "E is the old incarnation"case: the entry will be skipped.Also change nf_ct_should_gc() to first check the confirmed bit.The gc sequence is: 1. Check if entry has expired, if not skip to next entry 2. Obtain a reference to the expired entry. 3. Call nf_ct_should_gc() to double-check step 1.nf_ct_should_gc() is thus called only for entries that already failed anexpiry check. After this patch, once the confirmed bit check pas---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38473 Severity: Moderate CVSS3 score: 4.7

Description: 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 commit1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()").Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executedunder l2cap_sock_resume_cb(), we can avoid the issue simply by checkingif 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:1711Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPTHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Workqueue: hci0 hci_rx_workCall 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38496 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:dm-bufio: fix sched in atomic contextIf "try_verify_in_tasklet" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEPis enabled for dm-bufio. However, when bufio tries to evict buffers, thereis a chance to trigger scheduling in spin_lock_bh, the following warningis hit:BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2preempt_count: 201, expected: 0RCU nest depth: 0, expected: 04 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/0x710Preemption disabled at:[<0000000000000000>] 0x0CPU: 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/2014Workqueue: dm_bufio_cache do_global_cleanupCall Trace: 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 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 1 sha256 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]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38544 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix bug due to prealloc collisionWhen userspace is using AF_RXRPC to provide a server, it has to preallocateincoming calls and assign to them call IDs that will be used to threadrelated recvmsg() and sendmsg() together. The preallocated call IDs willautomatically be attached to calls as they come in until the pool is empty.To the kernel, the call IDs are just arbitrary numbers, but userspace canuse the call ID to hold a pointer to prepared structs. In any case, theuser isn't permitted to create two calls with the same call ID (call IDsbecome available again when the call ends) and EBADSLT should result fromsendmsg() if an attempt is made to preallocate a call with an in-use callID.However, the cleanup in the error handling will trigger both assertions inrxrpc_cleanup_call() because the call isn't marked complete and isn'tmarked as having been released.Fix this by setting the call state in rxrpc_service_prealloc_one() and thenmarking it as being released before calling the cleanup function.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38546 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix memory leak of struct clip_vcc.ioctl(ATMARP_MKIP) allocates struct clip_vcc and set it tovcc->user_back.The code assumes that vcc_destroy_socket() passes NULL skbto vcc->push() when the socket is close()d, and then clip_push()frees clip_vcc.However, ioctl(ATMARPD_CTRL) sets NULL to vcc->push() inatm_init_atmarp(), resulting in memory leak.Let's serialise two ioctl() by lock_sock() and check vcc->push()in atm_init_atmarp() to prevent memleak.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38576 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/eeh: Make EEH driver device hotplug safeMultiple race conditions existed between the PCIe hotplug driver and theEEH driver, leading to a variety of kernel oopses of the same generalnature:A second class of oops is also seen when the underlying bus disappearsduring device recovery.Refactor the EEH module to be PCI rescan and remove safe. Also cleanup a few minor formatting / readability issues.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38593 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'Function 'hci_discovery_filter_clear()' frees 'uuids' array and thensets it to NULL. There is a tiny chance of the following race:'hci_cmd_sync_work()' 'update_passive_scan_sync()' 'hci_update_passive_scan_sync()' 'hci_discovery_filter_clear()' kfree(uuids); <-------------------------preempted--------------------------------> 'start_service_discovery()' 'hci_discovery_filter_clear()' kfree(uuids); // DOUBLE FREE <-------------------------preempted--------------------------------> uuids = NULL;To fix it let's add locking around 'kfree()' call and NULL pointerassignment. Otherwise the following backtrace fires:[ ] ------------[ cut here ]------------[ ] kernel BUG at mm/slub.c:547![ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP[ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1[ ] Tainted: [O]=OOT_MODULE[ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ ] pc : __slab_free+0xf8/0x348[ ] lr : __slab_free+0x48/0x348...[ ] Call trace:[ ] __slab_free+0xf8/0x348[ ] kfree+0x164/0x27c[ ] start_service_discovery+0x1d0/0x2c0[ ] hci_sock_sendmsg+0x518/0x924[ ] __sock_sendmsg+0x54/0x60[ ] sock_write_iter+0x98/0xf8[ ] do_iter_readv_writev+0xe4/0x1c8[ ] vfs_writev+0x128/0x2b0[ ] do_writev+0xfc/0x118[ ] __arm64_sys_writev+0x20/0x2c[ ] invoke_syscall+0x68/0xf0[ ] el0_svc_common.constprop.0+0x40/0xe0[ ] do_el0_svc+0x1c/0x28[ ] el0_svc+0x30/0xd0[ ] el0t_64_sync_handler+0x100/0x12c[ ] el0t_64_sync+0x194/0x198[ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000)[ ] ---[ end trace 0000000000000000 ]---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38595 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:xen: fix UAF in dmabuf_exp_from_pages()[dma_buf_fd() fixes; no preferences regarding the tree it goes through -up to xen folks]As soon as we'd inserted a file reference into descriptor table, anotherthread could close it. That's fine for the case when all we are doing isreturning that descriptor to userland (it's a race, but it's a userlandrace and there's nothing the kernel can do about it). However, if wefollow fd_install() with any kind of access to objects that would bedestroyed on close (be it the struct file itself or anything destroyedby its ->release()), we have a UAF.dma_buf_fd() is a combination of reserving a descriptor and fd_install().gntdev dmabuf_exp_from_pages() calls it and then proceeds to access theobjects destroyed on close - starting with gntdev_dmabuf itself.Fix that by doing reserving descriptor before anything else and dofd_install() only when everything had been set up.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38632 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:pinmux: fix race causing mux_owner NULL with active mux_usecountcommit 5a3e85c3c397 ("pinmux: Use sequential access to accessdesc->pinmux data") tried to address the issue when two client of thesame gpio calls pinctrl_select_state() for the same functionality, wasresulting in NULL pointer issue while accessing desc->mux_owner.However, issue was not completely fixed due to the way it was handledand it can still result in the same NULL pointer.The issue occurs due to the following interleaving: cpu0 (process A) cpu1 (process B) pin_request() { pin_free() { mutex_lock() desc->mux_usecount--; //becomes 0 .. mutex_unlock() mutex_lock(desc->mux) desc->mux_usecount++; // becomes 1 desc->mux_owner = owner; mutex_unlock(desc->mux) mutex_lock(desc->mux) desc->mux_owner = NULL; mutex_unlock(desc->mux)This sequence leads to a state where the pin appears to be in use(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which cancause NULL pointer on next pin_request on the same pin.Ensure that updates to mux_usecount and mux_owner are performedatomically under the same lock. Only clear mux_owner when mux_usecountreaches zero and no new owner has been assigned.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38650 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: remove mutex_lock check in hfsplus_free_extentsSyzbot reported an issue in hfsplus filesystem:------------[ cut here ]------------WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346 hfsplus_free_extents+0x700/0xad0Call Trace:hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56cont_expand_zero fs/buffer.c:2383 [inline]cont_write_begin+0x2cf/0x860 fs/buffer.c:2446hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263notify_change+0xe38/0x10f0 fs/attr.c:420do_truncate+0x1fb/0x2e0 fs/open.c:65do_sys_ftruncate+0x2eb/0x380 fs/open.c:193do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdTo avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlockon file truncation") unlock extree before hfsplus_free_extents(),and add check wheather extree is locked in hfsplus_free_extents().However, when operations such as hfsplus_file_release,hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executedconcurrently in different files, it is very likely to trigger theWARN_ON, which will lead syzbot and xfstest to consider it as anabnormality.The comment above this warning also describes one of the easytriggering situations, which can easily trigger and causexfstest&syzbot to report errors.[task A] [task B]->hfsplus_file_release ->hfsplus_file_truncate ->hfs_find_init ->mutex_lock ->mutex_unlock ->hfsplus_write_begin ->hfsplus_get_block ->hfsplus_file_extend ->hfsplus_ext_read_extent ->hfs_find_init ->mutex_lock ->hfsplus_free_extents WARN_ON(mutex_is_locked) !!!Several threads could try to lock the shared extents tree.And warning can be triggered in one thread when another threadhas locked the tree. This is the wrong behavior of the code andwe need to remove the warning.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38676 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Avoid stack buffer overflow from kernel cmdlineWhile the kernel command line is considered trusted in most environments,avoid writing 1 byte past the end of "acpiid" if the "str" argument ismaximum length.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38695 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structureIf a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, theresultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() mayoccur before sli4_hba.hdwqs are allocated. This may result in a nullpointer dereference when attempting to take the abts_io_buf_list_lock forthe first hardware queue. Fix by adding a null ptr check onphba->sli4_hba.hdwq and early return because this situation means theremust have been an error during port initialization.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38701 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: do not BUG when INLINE_DATA_FL lacks system.data xattrA syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data()when an inode had the INLINE_DATA_FL flag set but was missing thesystem.data extended attribute.Since this can happen due to a maiciouly fuzzed file system, weshouldn't BUG, but rather, report it as a corrupted file system.Add similar replacements of BUG_ON with EXT4_ERROR_INODE() iiext4_create_inline_data() and ext4_inline_data_truncate().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38706 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()snd_soc_remove_pcm_runtime() might be called with rtd == NULL which willleads to null pointer dereference.This was reproduced with topology loading and marking a link as ignoredue to missing hardware component on the system.On module removal the soc_tplg_remove_link() would callsnd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,no runtime was created.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39736 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lockWhen netpoll is enabled, calling pr_warn_once() while holdingkmemleak_lock in mem_pool_alloc() can cause a deadlock due to lockinversion with the netconsole subsystem. This occurs becausepr_warn_once() may trigger netpoll, which eventually leads to__alloc_skb() and back into kmemleak code, attempting to reacquirekmemleak_lock.This is the path for the deadlock.mem_pool_alloc() -> raw_spin_lock_irqsave(&kmemleak_lock, flags); -> pr_warn_once() -> netconsole subsystem -> netpoll -> __alloc_skb -> __create_object -> raw_spin_lock_irqsave(&kmemleak_lock, flags);Fix this by setting a flag and issuing the pr_warn_once() afterkmemleak_lock is released.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39792 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:dm: Always split write BIOs to zoned device limitsAny zoned DM target that requires zone append emulation will use theblock layer zone write plugging. In such case, DM target drivers mustnot split BIOs using dm_accept_partial_bio() as doing so can potentiallylead to deadlocks with queue freeze operations. Regular write operationsused to emulate zone append operations also cannot be split by thetarget driver as that would result in an invalid writen sector valuereturn using the BIO sector.In order for zoned DM target drivers to avoid such incorrect BIOsplitting, we must ensure that large BIOs are split before being passedto the map() function of the target, thus guaranteeing that thelimits for the mapped device are not exceeded.dm-crypt and dm-flakey are the only target drivers supporting zoneddevices and using dm_accept_partial_bio().In the case of dm-crypt, this function is used to split BIOs to theinternal max_write_size limit (which will be suppressed in a differentpatch). However, since crypt_alloc_buffer() uses a bioset allowing onlyup to BIO_MAX_VECS (256) vectors in a BIO. The dm-crypt devicemax_segments limit, which is not set and so default to BLK_MAX_SEGMENTS(128), must thus be respected and write BIOs split accordingly.In the case of dm-flakey, since zone append emulation is not required,the block layer zone write plugging is not used and no splitting of BIOsrequired.Modify the function dm_zone_bio_needs_split() to use the block layerhelper function bio_needs_zone_write_plugging() to force a call tobio_split_to_limits() in dm_split_and_process_bio(). This allows DMtarget drivers to avoid using dm_accept_partial_bio() for writeoperations on zoned DM devices.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39889 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: l2cap: Check encryption key size on incoming connectionThis is required for passing GAP/SEC/SEM/BI-04-C PTS test case: Security Mode 4 Level 4, Responder - Invalid Encryption Key Size - 128 bitThis tests the security key with size from 1 to 15 bytes while theSecurity Mode 4 Level 4 requests 16 bytes key size.Currently PTS fails with the following logs:- expected:Connection Response: Code: [3 (0x03)] Code Identifier: (lt)WildCard: Exists(gt) Length: [8 (0x0008)] Destination CID: (lt)WildCard: Exists(gt) Source CID: [64 (0x0040)] Result: [3 (0x0003)] Connection refused - Security block Status: (lt)WildCard: Exists(gt),but received:Connection Response: Code: [3 (0x03)] Code Identifier: [1 (0x01)] Length: [8 (0x0008)] Destination CID: [64 (0x0040)] Source CID: [64 (0x0040)] Result: [0 (0x0000)] Connection Successful Status: [0 (0x0000)] No further information availableAnd HCI logs:< HCI Command: Read Encrypti.. (0x05|0x0008) plen 2 Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)> HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 1 Status: Success (0x00) Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) Key size: 7> ACL Data RX: Handle 14 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 1 len 4 PSM: 4097 (0x1001) Source CID: 64< ACL Data TX: Handle 14 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 1 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39891 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Initialize the chan_stats array to zeroThe adapter->chan_stats[] array is initialized inmwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero outmemory. The array is filled in mwifiex_update_chan_statistics()and then the user can query the data in mwifiex_cfg80211_dump_survey().There are two potential issues here. What if the user callsmwifiex_cfg80211_dump_survey() before the data has been filled in.Also the mwifiex_update_chan_statistics() function doesn't necessarilyinitialize the whole array. Since the array was not initialized atthe start that could result in an information leak.Also this array is pretty small. It's a maximum of 900 bytes so it'smore appropriate to use kcalloc() instead vmalloc().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39953 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:cgroup: split cgroup_destroy_wq into 3 workqueuesA hung task can occur during [1] LTP cgroup testing when repeatedlymounting/unmounting perf_event and net_prio controllers withsystemd.unified_cgroup_hierarchy=1. The hang manifests incgroup_lock_and_drain_offline() during root destruction.Related case:cgroup_fj_function_perf_event cgroup_fj_function.sh perf_eventcgroup_fj_function_net_prio cgroup_fj_function.sh net_prioCall Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20Root Cause:CPU0 CPU1mount perf_event umount net_priocgroup1_get_tree cgroup_kill_sbrebind_subsystems // root destruction enqueues // cgroup_destroy_wq// kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to dieProblem scenario:1. CPU0 mounts perf_event (rebind_subsystems)2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work3. A dying perf_event CSS gets queued for offline after root destruction4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)Solution:Split cgroup_destroy_wq into three dedicated workqueues:cgroup_offline_wq - Handles CSS offline operationscgroup_release_wq - Manages resource releasecgroup_free_wq - Performs final memory deallocationThis separation eliminates blocking in the CSS free path while waiting foroffline operations to complete.[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40006 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix folio is still mapped when deletedMigration may be raced with fallocating hole. remove_inode_single_foliowill unmap the folio if the folio is still mapped. However, it's calledwithout folio lock. If the folio is migrated and the mapped pte has beenconverted to migration entry, folio_mapped() returns false, and won'tunmap it. Due to extra refcount held by remove_inode_single_folio,migration fails, restores migration entry to normal pte, and the folio ismapped again. As a result, we triggered BUG in filemap_unaccount_folio.The log is as follows: BUG: Bad page cache in process hugetlb pfn:156c00 page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00 head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0 aops:hugetlbfs_aops ino:dcc dentry name(?):"my_hugepage_file" flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f4(hugetlb) page dumped because: still mapped when deleted CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x4f/0x70 filemap_unaccount_folio+0xc4/0x1c0 __filemap_remove_folio+0x38/0x1c0 filemap_remove_folio+0x41/0xd0 remove_inode_hugepages+0x142/0x250 hugetlbfs_fallocate+0x471/0x5a0 vfs_fallocate+0x149/0x380Hold folio lock before checking if the folio is mapped to avold race withmigration.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40012 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix warning in smc_rx_splice() when calling get_page()smc_lo_register_dmb() allocates DMB buffers with kzalloc(), which arelater passed to get_page() in smc_rx_splice(). Since kmalloc memory isnot page-backed, this triggers WARN_ON_ONCE() in get_page() and preventsholding a refcount on the buffer. This can lead to use-after-free ifthe memory is released before splice_to_pipe() completes.Use folio_alloc() instead, ensuring DMBs are page-backed and safe forget_page().WARNING: CPU: 18 PID: 12152 at ./include/linux/mm.h:1330 smc_rx_splice+0xaf8/0xe20 [smc]CPU: 18 UID: 0 PID: 12152 Comm: smcapp Kdump: loaded Not tainted 6.17.0-rc3-11705-g9cf4672ecfee #10 NONEHardware name: IBM 3931 A01 704 (z/VM 7.4.0)Krnl PSW : 0704e00180000000 000793161032696c (smc_rx_splice+0xafc/0xe20 [smc]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3Krnl GPRS: 0000000000000000 001cee80007d3001 00077400000000f8 0000000000000005 0000000000000001 001cee80007d3006 0007740000001000 001c000000000000 000000009b0c99e0 0000000000001000 001c0000000000f8 001c000000000000 000003ffcc6f7c88 0007740003e98000 0007931600000005 000792969b2ff7b8Krnl Code: 0007931610326960: af000000 mc 0,0 0007931610326964: a7f4ff43 brc 15,00079316103267ea #0007931610326968: af000000 mc 0,0 >000793161032696c: a7f4ff3f brc 15,00079316103267ea 0007931610326970: e320f1000004 lg %r2,256(%r15) 0007931610326976: c0e53fd1b5f5 brasl %r14,000793168fd5d560 000793161032697c: a7f4fbb5 brc 15,00079316103260e6 0007931610326980: b904002b lgr %r2,%r11Call Trace: smc_rx_splice+0xafc/0xe20 [smc] smc_rx_splice+0x756/0xe20 [smc]) smc_rx_recvmsg+0xa74/0xe00 [smc] smc_splice_read+0x1ce/0x3b0 [smc] sock_splice_read+0xa2/0xf0 do_splice_read+0x198/0x240 splice_file_to_pipe+0x7e/0x110 do_splice+0x59e/0xde0 __do_splice+0x11a/0x2d0 __s390x_sys_splice+0x140/0x1f0 __do_syscall+0x122/0x280 system_call+0x6e/0x90Last Breaking-Event-Address:smc_rx_splice+0x960/0xe20 [smc]---[ end trace 0000000000000000 ]---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40047 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/waitid: always prune wait queue entry in io_waitid_wait()For a successful return, always remove our entry from the wait queueentry list. Previously this was skipped if a cancelation was inprogress, but this can race with another invocation of the wait queueentry callback.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40111 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix Use-after-free in validationNodes stored in the validation duplicates hashtable come from an arenaallocator that is cleared at the end of vmw_execbuf_process. All nodesare expected to be cleared in vmw_validation_drop_ht but this node escapedbecause its resource was destroyed prematurely.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40134 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix NULL pointer dereference in __dm_suspend()There is a race condition between dm device suspend and table load thatcan lead to null pointer dereference. The issue occurs when suspend isinvoked before table load completes:BUG: kernel NULL pointer dereference, address: 0000000000000054Oops: 0000 [#1] PREEMPT SMP PTICPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50Call Trace: blk_mq_quiesce_queue+0x2c/0x50 dm_stop_queue+0xd/0x20 __dm_suspend+0x130/0x330 dm_suspend+0x11a/0x180 dev_suspend+0x27e/0x560 ctl_ioctl+0x4cf/0x850 dm_ctl_ioctl+0xd/0x20 vfs_ioctl+0x1d/0x50 __se_sys_ioctl+0x9b/0xc0 __x64_sys_ioctl+0x19/0x30 x64_sys_call+0x2c4a/0x4620 do_syscall_64+0x9e/0x1b0The issue can be triggered as below:T1 T2dm_suspend table_load__dm_suspend dm_setup_md_queue dm_mq_init_request_queue blk_mq_init_allocated_queue => q->mq_ops = set->ops; (1)dm_stop_queue / dm_wait_for_completion=> q->tag_set NULL pointer! (2) => q->tag_set = set; (3)Fix this by checking if a valid table (map) exists before performingrequest-based suspend and waiting for target I/O. When map is NULL,skip these table-dependent suspend steps.Even when map is NULL, no I/O can reach any target because there isno table loaded; I/O submitted in this state will fail early in theDM layer. Skipping the table-dependent suspend logic in this caseis safe and avoids NULL pointer dereferences.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40142 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RTsnd_pcm_group_lock_irq() acquires a spinlock_t and disables interruptsvia spin_lock_irq(). This also implicitly disables the handling ofsoftirqs such as TIMER_SOFTIRQ.On PREEMPT_RT softirqs are preemptible and spin_lock_irq() does notdisable them. That means a timer can be invoked during spin_lock_irq()on the same CPU. Due to synchronisations reasons local_bh_disable() hasa per-CPU lock named softirq_ctrl.lock which synchronizes individualsoftirq against each other.syz-bot managed to trigger a lockdep report where softirq_ctrl.lock isacquired in hrtimer_cancel() in addition to hrtimer_run_softirq(). Thisis a possible deadlock.The softirq_ctrl.lock can not be made part of spin_lock_irq() as thiswould lead to too much synchronisation against individual threads on thesystem. To avoid the possible deadlock, softirqs must be manuallydisabled before the lock is acquired.Disable softirqs before the lock is acquired on PREEMPT_RT.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40146 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix potential deadlock while nr_requests grownAllocate and free sched_tags while queue is freezed can deadlock[1],this is a long term problem, hence allocate memory before freezingqueue and free memory after queue is unfreezed.[1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40164 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: Fix using smp_processor_id() in preemptible code warningsSyzbot reported the following warning:BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary)Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 __dev_set_mtu net/core/dev.c:9443 [inline] netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821 sock_do_ioctl+0x19d/0x280 net/socket.c:1204 sock_ioctl+0x42f/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFor historical and portability reasons, the netif_rx() is usuallyrun in the softirq or interrupt context, this commit therefore addlocal_bh_disable/enable() protection in the usbnet_resume_rx().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40165 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:media: nxp: imx8-isi: m2m: Fix streaming cleanup on releaseIf streamon/streamoff calls are imbalanced, such as when exiting anapplication with Ctrl+C when streaming, the m2m usage_count will neverreach zero and the ISI channel won't be freed. Besides from that, if theinput line width is more than 2K, it will trigger a WARN_ON():[ 59.222120] ------------[ cut here ]------------[ 59.226758] WARNING: drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c:631 at mxc_isi_channel_chain+0xa4/0x120, CPU#4: v4l2-ctl/654[ 59.238569] Modules linked in: ap1302[ 59.242231] CPU: 4 UID: 0 PID: 654 Comm: v4l2-ctl Not tainted 6.16.0-rc4-next-20250704-06511-gff0e002d480a-dirty #258 PREEMPT[ 59.253597] Hardware name: NXP i.MX95 15X15 board (DT)[ 59.258720] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 59.265669] pc : mxc_isi_channel_chain+0xa4/0x120[ 59.270358] lr : mxc_isi_channel_chain+0x44/0x120[ 59.275047] sp : ffff8000848c3b40[ 59.278348] x29: ffff8000848c3b40 x28: ffff0000859b4c98 x27: ffff800081939f00[ 59.285472] x26: 000000000000000a x25: ffff0000859b4cb8 x24: 0000000000000001[ 59.292597] x23: ffff0000816f4760 x22: ffff0000816f4258 x21: ffff000084ceb780[ 59.299720] x20: ffff000084342ff8 x19: ffff000084340000 x18: 0000000000000000[ 59.306845] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffdb369e1c[ 59.313969] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000[ 59.321093] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000[ 59.328217] x8 : ffff8000848c3d48 x7 : ffff800081930b30 x6 : ffff800081930b30[ 59.335340] x5 : ffff0000859b6000 x4 : ffff80008193ae80 x3 : ffff800081022420[ 59.342464] x2 : ffff0000852f6900 x1 : 0000000000000001 x0 : ffff000084341000[ 59.349590] Call trace:[ 59.352025] mxc_isi_channel_chain+0xa4/0x120 (P)[ 59.356722] mxc_isi_m2m_streamon+0x160/0x20c[ 59.361072] v4l_streamon+0x24/0x30[ 59.364556] __video_do_ioctl+0x40c/0x4a0[ 59.368560] video_usercopy+0x2bc/0x690[ 59.372382] video_ioctl2+0x18/0x24[ 59.375857] v4l2_ioctl+0x40/0x60[ 59.379168] __arm64_sys_ioctl+0xac/0x104[ 59.383172] invoke_syscall+0x48/0x104[ 59.386916] el0_svc_common.constprop.0+0xc0/0xe0[ 59.391613] do_el0_svc+0x1c/0x28[ 59.394915] el0_svc+0x34/0xf4[ 59.397966] el0t_64_sync_handler+0xa0/0xe4[ 59.402143] el0t_64_sync+0x198/0x19c[ 59.405801] ---[ end trace 0000000000000000 ]---Address this issue by moving the streaming preparation and cleanup tothe vb2 .prepare_streaming() and .unprepare_streaming() operations. Thisalso simplifies the driver by allowing direct usage of thev4l2_m2m_ioctl_streamon() and v4l2_m2m_ioctl_streamoff() helpers.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40173 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net/ip6_tunnel: Prevent perpetual tunnel growthSimilarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too.While ipv4 tunnel headroom adjustment growth was limited incommit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"),ipv6 tunnel yet increases the headroom without any ceiling.Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.Credits to Francesco Ruggeri, who was originally debugging this issueand wrote local Arista-specific patch and a reproducer.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40175 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: cleanup remaining SKBs in PTP flowsWhen the driver requests Tx timestamp value, one of the first steps isto clone SKB using skb_get. It increases the reference counter for thatSKB to prevent unexpected freeing by another component.However, there may be a case where the index is requested, SKB isassigned and never consumed by PTP flows - for example due to reset duringrunning PTP apps.Add a check in release timestamping function to verify if the SKBassigned to Tx timestamp latch was freed, and release remaining SKBs.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40179 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: verify orphan file size is not too bigIn principle orphan file can be arbitrarily large. However orphan replayneeds to traverse it all and we also pin all its buffers in memory. Thusfilesystems with absurdly large orphan files can lead to big amounts ofmemory consumed. Limit orphan file size to a sane value and also usekvmalloc() for allocating array of block descriptor structures to avoidlarge order allocations for sane but large orphan files.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40194 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request()The cpufreq_cpu_put() call in update_qos_request() takes place too earlybecause the latter subsequently calls freq_qos_update_request() thatindirectly accesses the policy object in question through the QoS requestobject passed to it.Fortunately, update_qos_request() is called under intel_pstate_driver_lock,so this issue does not matter for changing the intel_pstate operationmode, but it theoretically can cause a crash to occur on CPU device hotremoval (which currently can only happen in virt, but it is formallysupported nevertheless).Address this issue by modifying update_qos_request() to drop thereference to the policy later.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40209 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix memory leak of qgroup_list in btrfs_add_qgroup_relationWhen btrfs_add_qgroup_relation() is called with invalid qgroup levels(src >= dst), the function returns -EINVAL directly without freeing thepreallocated qgroup_list structure passed by the caller. This causes amemory leak because the caller unconditionally sets the pointer to NULLafter the call, preventing any cleanup.The issue occurs because the level validation check happens before themutex is acquired and before any error handling path that would freethe prealloc pointer. On this early return, the cleanup code at the'out' label (which includes kfree(prealloc)) is never reached.In btrfs_ioctl_qgroup_assign(), the code pattern is: prealloc = kzalloc(sizeof(*prealloc), GFP_KERNEL); ret = btrfs_add_qgroup_relation(trans, sa->src, sa->dst, prealloc); prealloc = NULL; // Always set to NULL regardless of return value ... kfree(prealloc); // This becomes kfree(NULL), does nothingWhen the level check fails, 'prealloc' is never freed by either thecallee or the caller, resulting in a 64-byte memory leak per failedoperation. This can be triggered repeatedly by an unprivileged userwith access to a writable btrfs mount, potentially exhausting kernelmemory.Fix this by freeing prealloc before the early return, ensuring preallocis always freed on all error paths.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40268 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: client: fix memory leak in smb3_fs_context_parse_paramThe user calls fsconfig twice, but when the program exits, free() onlyfrees ctx->source for the second fsconfig, not the first.Regarding fc->source, there is no code in the fs context related to itsmemory reclamation.To fix this memory leak, release the source memory corresponding to ctxor fc before each parsing.syzbot reported:BUG: memory leakunreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444BUG: memory leakunreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68321 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: always add GFP_NOWARN for ATOMIC allocationsDriver authors often forget to add GFP_NOWARN for page allocationfrom the datapath. This is annoying to users as OOMs are a factof life, and we pretty much expect network Rx to hit page allocationfailures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocationsby default.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68327 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:usb: renesas_usbhs: Fix synchronous external abort on unbindA synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind isexecuted after the configuration sequence described above:modprobe usb_f_ecmmodprobe libcompositemodprobe configfscd /sys/kernel/config/usb_gadgetmkdir -p g1cd g1echo "0x1d6b" > idVendorecho "0x0104" > idProductmkdir -p strings/0x409echo "0123456789" > strings/0x409/serialnumberecho "Renesas." > strings/0x409/manufacturerecho "Ethernet Gadget" > strings/0x409/productmkdir -p functions/ecm.usb0mkdir -p configs/c.1mkdir -p configs/c.1/strings/0x409echo "ECM" > configs/c.1/strings/0x409/configurationif [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1fiecho 11e20000.usb > UDCecho 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbindThe displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1The issue occurs because usbhs_sys_function_pullup(), which accesses the IPregisters, is executed after the USBHS clocks have been disabled. Theproblem is reproducible on the Renesas RZ/G3S SoC starting with theaddition of module stop in the clock enable/disable APIs. With module stopfunctionality enabled, a bus error is expected if a master accesses amodule whose clock has been stopped and module stop activated.Disable the IP clocks at the end of remove.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68745 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Clear cmds after chip resetCommit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handlingand host reset handling") caused two problems:1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.2. BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs().So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" andpartially revert "scsi: qla2xxx: target: Fix offline port handling andhost reset handling" at __qla2x00_abort_all_cmds.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68746 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:spi: tegra210-quad: Fix timeout handlingWhen the CPU that the QSPI interrupt handler runs on (typically CPU 0)is excessively busy, it can lead to rare cases of the IRQ thread notrunning before the transfer timeout is reached.While handling the timeouts, any pending transfers are cleaned up andthe message that they correspond to is marked as failed, which leavesthe curr_xfer field pointing at stale memory.To avoid this, clear curr_xfer to NULL upon timeout and check for thiscondition when the IRQ thread is finally run.While at it, also make sure to clear interrupts on failure so that newinterrupts can be run.A better, more involved, fix would move the interrupt clearing into ahard IRQ handler. Ideally we would also want to signal that the IRQthread no longer needs to be run after the timeout is hit to avoid theextra check for a valid transfer.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68749 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Fix race condition when unbinding BOsFix 'Memory manager not clean during takedown' warning that occurswhen ivpu_gem_bo_free() removes the BO from the BOs list before itgets unmapped. Then file_priv_unbind() triggers a warning indrm_mm_takedown() during context teardown.Protect the unmapping sequence with bo_list_lock to ensure the BO isalways fully unmapped when removed from the list. This ensures the BOis either fully unmapped at context teardown time or present on thelist and unmapped by file_priv_unbind().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68756 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lockblk_mq_{add,del}_queue_tag_set() functions add and remove queues fromtagset, the functions make sure that tagset and queues are marked asshared when two or more queues are attached to the same tagset.Initially a tagset starts as unshared and when the number of addedqueues reaches two, blk_mq_add_queue_tag_set() marks it as shared alongwith all the queues attached to it. When the number of attached queuesdrops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset andthe remaining queues as unshared.Both functions need to freeze current queues in tagset before setting onunsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functionshold set->tag_list_lock mutex, which makes sense as we do not wantqueues to be added or deleted in the process. This used to work fineuntil commit 98d81f0df70c ("nvme: use blk_mq_[un]quiesce_tagset")made the nvme driver quiesce tagset instead of quiscing individualqueues. blk_mq_quiesce_tagset() does the job and quiesce the queues inset->tag_list while holding set->tag_list_lock also.This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53The top stacktrace is showing nvme_timeout() called to handle nvmecommand timeout. timeout handler is trying to disable the controller andas a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq notto call queue callback handlers. The thread is stuck waiting forset->tag_list_lock as it tries to walk the queues in set->tag_list.The lock is held by the second thread in the bottom stack which iswaiting for one of queues to be frozen. The queue usage counter willdrop to zero after nvme_timeout() finishes, and this will not happenbecause the thread will wait for this mutex forever.Given that [un]quiescing queue is an operation that does not need tosleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of takingset->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCUsafe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list)in blk_mq_del_queue_tag_set() because we can not re-initialize it whilethe list is being traversed under RCU. The deleted queue will not beadded/deleted to/from a tagset and it will be freed in blk_free_queue()after the end of RCU grace period.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68772 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid updating compression context during writebackBai, Shuangpeng reported a bug as below:Oops: divide error: 0000 [#1] SMP KASAN PTICPU: 0 UID: 0 PID: 11441 Comm: syz.0.46 Not tainted 6.17.0 #1 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:f2fs_all_cluster_page_ready+0x106/0x550 fs/f2fs/compress.c:857Call Trace: f2fs_write_cache_pages fs/f2fs/data.c:3078 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3290 [inline] f2fs_write_data_pages+0x1c19/0x3600 fs/f2fs/data.c:3317 do_writepages+0x38e/0x640 mm/page-writeback.c:2634 filemap_fdatawrite_wbc mm/filemap.c:386 [inline] __filemap_fdatawrite_range mm/filemap.c:419 [inline] file_write_and_wait_range+0x2ba/0x3e0 mm/filemap.c:794 f2fs_do_sync_file+0x6e6/0x1b00 fs/f2fs/file.c:294 generic_write_sync include/linux/fs.h:3043 [inline] f2fs_file_write_iter+0x76e/0x2700 fs/f2fs/file.c:5259 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x7e9/0xe00 fs/read_write.c:686 ksys_write+0x19d/0x2d0 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf7/0x470 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe bug was triggered w/ below race condition:fsync setattr ioctl- f2fs_do_sync_file - file_write_and_wait_range - f2fs_write_cache_pages : inode is non-compressed : cc.cluster_size = F2FS_I(inode)->i_cluster_size = 0 - tag_pages_for_writeback - f2fs_setattr - truncate_setsize - f2fs_truncate - f2fs_fileattr_set - f2fs_setflags_common - set_compress_context : F2FS_I(inode)->i_cluster_size = 4 : set_inode_flag(inode, FI_COMPRESSED_FILE) - f2fs_compressed_file : return true - f2fs_all_cluster_page_ready : "pgidx % cc->cluster_size" trigger dividing 0 issueLet's change as below to fix this issue:- introduce a new atomic type variable .writeback in structure f2fs_inode_infoto track the number of threads which calling f2fs_write_cache_pages().- use .i_sem lock to protect .writeback update.- check .writeback before update compression context in f2fs_setflags_common()to avoid race w/ ->writepages.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68778 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't log conflicting inode if it's a dir moved in the current transactionWe can't log a conflicting inode if it's a directory and it was movedfrom one parent directory to another parent directory in the currenttransaction, as this can result an attempt to have a directory withtwo hard links during log replay, one for the old parent directory andanother for the new parent directory.The following scenario triggers that issue:1) We have directories "dir1" and "dir2" created in a past transaction. Directory "dir1" has inode A as its parent directory;2) We move "dir1" to some other directory;3) We create a file with the name "dir1" in directory inode A;4) We fsync the new file. This results in logging the inode of the new file and the inode for the directory "dir1" that was previously moved in the current transaction. So the log tree has the INODE_REF item for the new location of "dir1";5) We move the new file to some other directory. This results in updating the log tree to included the new INODE_REF for the new location of the file and removes the INODE_REF for the old location. This happens during the rename when we call btrfs_log_new_name();6) We fsync the file, and that persists the log tree changes done in the previous step (btrfs_log_new_name() only updates the log tree in memory);7) We have a power failure;8) Next time the fs is mounted, log replay happens and when processing the inode for directory "dir1" we find a new INODE_REF and add that link, but we don't remove the old link of the inode since we have not logged the old parent directory of the directory inode "dir1".As a result after log replay finishes when we trigger writeback of thesubvolume tree's extent buffers, the tree check will detect that we havea directory a hard link count of 2 and we get a mount failure.The errors and stack traces reported in dmesg/syslog are like this: [ 3845.729764] BTRFS info (device dm-0): start tree-log replay [ 3845.730304] page: refcount:3 mapcount:0 mapping:000000005c8a3027 index:0x1d00 pfn:0x11510c [ 3845.731236] memcg:ffff9264c02f4e00 [ 3845.731751] aops:btree_aops [btrfs] ino:1 [ 3845.732300] flags: 0x17fffc00000400a(uptodate|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [ 3845.733346] raw: 017fffc00000400a 0000000000000000 dead000000000122 ffff9264d978aea8 [ 3845.734265] raw: 0000000000001d00 ffff92650e6d4738 00000003ffffffff ffff9264c02f4e00 [ 3845.735305] page dumped because: eb page dump [ 3845.735981] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=6 ino=257, invalid nlink: has 2 expect no more than 1 for dir [ 3845.737786] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14881 owner 5 [ 3845.737789] BTRFS info (device dm-0): refs 4 lock_owner 0 current 30701 [ 3845.737792] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [ 3845.737794] inode generation 3 transid 9 size 16 nbytes 16384 [ 3845.737795] block group 0 mode 40755 links 1 uid 0 gid 0 [ 3845.737797] rdev 0 sequence 2 flags 0x0 [ 3845.737798] atime 1764259517.0 [ 3845.737800] ctime 1764259517.572889464 [ 3845.737801] mtime 1764259517.572889464 [ 3845.737802] otime 1764259517.0 [ 3845.737803] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [ 3845.737805] index 0 name_len 2 [ 3845.737807] item 2 key (256 DIR_ITEM 2363071922) itemoff 16077 itemsize 34 [ 3845.737808] location key (257 1 0) type 2 [ 3845.737810] transid 9 data_len 0 name_len 4 [ 3845.737811] item 3 key (256 DIR_ITEM 2676584006) itemoff 16043 itemsize 34 [ 3845.737813] location key (258 1 0) type 2 [ 3845.737814] transid 9 data_len 0 name_len 4 [ 3845.737815] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [ 3845.737816] location key (257 1 0) type 2 [---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68784 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: fix a UAF problem in xattr repairThe xchk_setup_xattr_buf function can allocate a new value buffer, whichmeans that any reference to ab->value before the call could become adangling pointer. Fix this by moving an assignment to after the buffersetup.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68788 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:fsnotify: do not generate ACCESS/MODIFY events on child for special filesinotify/fanotify do not allow users with no read access to a file tosubscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow thesame user to subscribe for watching events on children when the userhas access to the parent directory (e.g. /dev).Users with no read access to a file but with read access to its parentdirectory can still stat the file and see if it was accessed/modifiedvia atime/mtime change.The same is not true for special files (e.g. /dev/null). Users will notgenerally observe atime/mtime changes when other users read/write tospecial files, only when someone sets atime/mtime via utimensat().Align fsnotify events with this stat behavior and do not generateACCESS/MODIFY events to parent watchers on read/write of special files.The events are still generated to parent watchers on utimensat(). Thiscloses some side-channels that could be possibly used for informationexfiltration [1].[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68798 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/amd: Check event before enable to avoid GPFOn AMD machines cpuc->events[idx] can become NULL in a subtle racecondition with NMI->throttle->x86_pmu_stop().Check event for NULL in amd_pmu_enable_all() before enable to avoid a GPF.This appears to be an AMD only issue.Syzkaller reported a GPF in amd_pmu_enable_all.INFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143 msecsOops: general protection fault, probably for non-canonical address 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7]CPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzkRIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195 arch/x86/events/core.c:1430)RSP: 0018:ffff888118009d60 EFLAGS: 00010012RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002R13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601FS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0Call Trace: amd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2))x86_pmu_enable (arch/x86/events/core.c:1360)event_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186 kernel/events/core.c:2346)__perf_remove_from_context (kernel/events/core.c:2435)event_function (kernel/events/core.c:259)remote_function (kernel/events/core.c:92 (discriminator 1) kernel/events/core.c:72 (discriminator 1))__flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64 kernel/smp.c:135 kernel/smp.c:540)__sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272)sysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47) arch/x86/kernel/smp.c:266 (discriminator 47))

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-68820 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: xattr: fix null pointer deref in ext4_raw_inode()If ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED),iloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all()lacks error checking, this will lead to a null pointer dereferencein ext4_raw_inode(), called right after ext4_get_inode_loc().Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71071 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: fix use-after-free on probe deferralThe driver is dropping the references taken to the larb devices duringprobe after successful lookup as well as on errors. This canpotentially lead to a use-after-free in case a larb device has not yetbeen bound to its driver so that the iommu driver probe defers.Fix this by keeping the references as expected while the iommu driver isbound.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71097 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: Fix reference count leak when using error routes with nexthop objectsWhen a nexthop object is deleted, it is marked as dead and thenfib_table_flush() is called to flush all the routes that are using thedead nexthop.The current logic in fib_table_flush() is to only flush error routes(e.g., blackhole) when it is called as part of network namespacedismantle (i.e., with flush_all=true). Therefore, error routes are notflushed when their nexthop object is deleted: # ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1As such, they keep holding a reference on the nexthop object which inturn holds a reference on the nexthop device, resulting in a referencecount leak: # ip link del dev dummy1 [ 70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2Fix by flushing error routes when their nexthop is marked as dead.IPv6 does not suffer from this problem.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71148 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net/handshake: restore destructor on submit failurehandshake_req_submit() replaces sk->sk_destruct but never restores it whensubmission fails before the request is hashed. handshake_sk_destruct() thenreturns early and the original destructor never runs, leaking the socket.Restore sk_destruct on the error path.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71150 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ksmbd: Fix refcount leak when invalid session is found on session lookupWhen a session is found but its state is not SMB2_SESSION_VALID, Itindicates that no valid session was found, but it is missing to decrementthe reference count acquired by the session lookup, which results ina reference count leak. This patch fixes the issue by explicitly callingksmbd_user_session_put to release the reference to the session.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71157 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: always drop device refcount in ib_del_sub_device_and_put()Since nldev_deldev() (introduced by commit 060c642b2ab8 ("RDMA/nldev: Addsupport to add/delete a sub IB device through netlink") grabs a referenceusing ib_device_get_by_index() before calling ib_del_sub_device_and_put(),we need to drop that reference before returning -EOPNOTSUPP error.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71193 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:phy: qcom-qusb2: Fix NULL pointer dereference on early suspendEnabling runtime PM before attaching the QPHY instance as driver datacan lead to a NULL pointer dereference in runtime PM callbacks thatexpect valid driver data. There is a small window where the suspendcallback may run after PM runtime enabling and before runtime forbid.This causes a sporadic crash during boot:```Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a1[...]CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.7+ #116 PREEMPTWorkqueue: pm pm_runtime_workpstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : qusb2_phy_runtime_suspend+0x14/0x1e0 [phy_qcom_qusb2]lr : pm_generic_runtime_suspend+0x2c/0x44[...]```Attach the QPHY instance as driver data before enabling runtime PM toprevent NULL pointer dereference in runtime PM callbacks.Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent ashort window where an unnecessary runtime suspend can occur.Use the devres-managed version to ensure PM runtime is symmetricallydisabled during driver removal for proper cleanup.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-22986 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:gpiolib: fix race condition for gdev->srcuIf two drivers were calling gpiochip_add_data_with_key(), one may betraversing the srcu-protected list in gpio_name_to_desc(), meanwhileother has just added its gdev in gpiodev_add_to_list_unlocked().This creates a non-mutexed and non-protected timeframe, when oneinstance is dereferencing and using &gdev->srcu, before the otherhas initialized it, resulting in crash:[ 4.935481] Unable to handle kernel paging request at virtual address ffff800272bcc000[ 4.943396] Mem abort info:[ 4.943400] ESR = 0x0000000096000005[ 4.943403] EC = 0x25: DABT (current EL), IL = 32 bits[ 4.943407] SET = 0, FnV = 0[ 4.943410] EA = 0, S1PTW = 0[ 4.943413] FSC = 0x05: level 1 translation fault[ 4.943416] Data abort info:[ 4.943418] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000[ 4.946220] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 4.955261] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 4.955268] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000038e6c000[ 4.961449] [ffff800272bcc000] pgd=0000000000000000[ 4.969203] , p4d=1000000039739003[ 4.979730] , pud=0000000000000000[ 4.980210] phandle (CPU): 0x0000005e, phandle (BE): 0x5e000000 for node "reset"[ 4.991736] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP...[ 5.121359] pc : __srcu_read_lock+0x44/0x98[ 5.131091] lr : gpio_name_to_desc+0x60/0x1a0[ 5.153671] sp : ffff8000833bb430[ 5.298440][ 5.298443] Call trace:[ 5.298445] __srcu_read_lock+0x44/0x98[ 5.309484] gpio_name_to_desc+0x60/0x1a0[ 5.320692] gpiochip_add_data_with_key+0x488/0xf00 5.946419] ---[ end trace 0000000000000000 ]---Move initialization code for gdev fields before it is added togpio_devices, with adjacent initialization code.Adjust goto statements to reflect modified order of operations[Bartosz: fixed a build issue, removed stray newline]

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23019 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: marvell: prestera: fix NULL dereference on devlink_alloc() failuredevlink_alloc() may return NULL on allocation failure, butprestera_devlink_alloc() unconditionally calls devlink_priv() onthe returned pointer.This leads to a NULL pointer dereference if devlink allocation fails.Add a check for a NULL devlink pointer and return NULL early to avoidthe crash.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23053 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix a deadlock involving nfs_release_folio()Wang Zhaolong reports a deadlock involving NFSv4.1 state recoverywaiting on kthreadd, which is attempting to reclaim memory by callingnfs_release_folio(). The latter cannot make progress due to staterecovery being needed.It seems that the only safe thing to do here is to kick off a writebackof the folio, without waiting for completion, or else kicking off anasynchronous commit.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23069 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: fix potential underflow in virtio_transport_get_credit()The credit calculation in virtio_transport_get_credit() uses unsignedarithmetic: ret = vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt);If the peer shrinks its advertised buffer (peer_buf_alloc) while bytesare in flight, the subtraction can underflow and produce a largepositive value, potentially allowing more data to be queued than thepeer can handle.Reuse virtio_transport_has_space() which already handles this case andadd a comment to make it clear why we are doing that.[Stefano: use virtio_transport_has_space() instead of duplicating the code][Stefano: tweak the commit message]

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23105 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_agThis is more of a preventive patch to make the code more consistent andto prevent possible exploits that employ child qlen manipulations on qfq.use cl_is_active instead of relying on the child qdisc's qlen to determineclass activation.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23110 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Wake up the error handler when final completions race against each otherThe fragile ordering between marking commands completed or failed sothat the error handler only wakes when the last running commandcompletes or times out has race conditions. These race conditions cancause the SCSI layer to fail to wake the error handler, leaving I/Othrough the SCSI host stuck as the error state cannot advance.First, there is an memory ordering issue within scsi_dec_host_busy().The write which clears SCMD_STATE_INFLIGHT may be reordered with readscounting in scsi_host_busy(). While the local CPU will see its ownwrite, reordering can allow other CPUs in scsi_dec_host_busy() orscsi_eh_inc_host_failed() to see a raised busy count, causing no CPU tosee a host busy equal to the host_failed count.This race condition can be prevented with a memory barrier on the errorpath to force the write to be visible before counting host busycommands.Second, there is a general ordering issue with scsi_eh_inc_host_failed(). Bycounting busy commands before incrementing host_failed, it can race with afinal command in scsi_dec_host_busy(), such that scsi_dec_host_busy() doesnot see host_failed incremented but scsi_eh_inc_host_failed() counts busycommands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),resulting in neither waking the error handler task.This needs the call to scsi_host_busy() to be moved after host_failed isincremented to close the race condition.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-38348 Severity: Moderate CVSS3 score: 4.6

Description: 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 valueto something that causes a crash/panic due to overrun.This patch addresses the issue by adding the size to the common devicecontext, so p54_rx_eeprom_readback no longer relies on possibly tamperedvalues... That said, it also checks if the "firmware" altered the valueand 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 proprietarylicense and as a reason, it is not present on most distributions bydefault.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68803 Severity: Moderate CVSS3 score: 4.6

Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: NFSv4 file creation neglects setting ACLAn NFSv4 client that sets an ACL with a named principal during filecreation retrieves the ACL afterwards, and finds that it is only adefault ACL (based on the mode bits) and not the ACL that wasrequested during file creation. This violates RFC 8881 section6.4.1.3: "the ACL attribute is set as given".The issue occurs in nfsd_create_setattr(), which callsnfsd_attrs_valid() to determine whether to call nfsd_setattr().However, nfsd_attrs_valid() checks only for iattr changes andsecurity labels, but not POSIX ACLs. When only an ACL is present,the function returns false, nfsd_setattr() is skipped, and thePOSIX ACL is never applied to the inode.Subsequently, when the client retrieves the ACL, the server findsno POSIX ACL on the inode and returns one generated from the file'smode bits rather than returning the originally-specified ACL.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-0840 Severity: Moderate CVSS3 score: 4.5

Description: A vulnerability, which was classified as problematic, was found in GNU Binutils up to 2.43. This affects the function disassemble_bytes of the file binutils/objdump.c. The manipulation of the argument buf leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. The identifier of the patch is baac6c221e9d69335bf41366a1c7d87d8ab2f893. It is recommended to upgrade the affected component.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-1176 Severity: Moderate CVSS3 score: 4.5

Description: A vulnerability was found in GNU Binutils 2.43 and classified as critical. This issue affects the function _bfd_elf_gc_mark_rsec of the file elflink.c of the component ld. The manipulation leads to heap-based buffer overflow. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. The patch is named f9978defb6fab0bd8583942d97c112b0932ac814. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-1182 Severity: Moderate CVSS3 score: 4.5

Description: A vulnerability, which was classified as critical, was found in GNU Binutils 2.43. Affected is the function bfd_elf_reloc_symbol_deleted_p of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The patch is identified as b425859021d17adf62f06fb904797cf8642986ad. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-38170 Severity: Moderate CVSS3 score: 4.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64/fpsimd: Discard stale CPU state when handling SME trapsThe logic for handling SME traps manipulates saved FPSIMD/SVE/SME stateincorrectly, and a race with preemption can result in a task havingTIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU stateis stale (e.g. with SME traps enabled). This can result in warnings fromdo_sme_acc() where SME traps are not expected while TIF_SME is set:| /* With TIF_SME userspace shouldn't generate any traps */| if (test_and_set_thread_flag(TIF_SME))| WARN_ON(1);This is very similar to the SVE issue we fixed in commit: 751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps")The race can occur when the SME trap handler is preempted before andafter manipulating the saved FPSIMD/SVE/SME state, starting and ending onthe same CPU, e.g.| void do_sme_acc(unsigned long esr, struct pt_regs *regs)| {| // Trap on CPU 0 with TIF_SME clear, SME traps enabled| // task->fpsimd_cpu is 0.| // per_cpu_ptr(&fpsimd_last_state, 0) is task.|| ...|| // Preempted; migrated from CPU 0 to CPU 1.| // TIF_FOREIGN_FPSTATE is set.|| get_cpu_fpsimd_context();|| /* With TIF_SME userspace shouldn't generate any traps */| if (test_and_set_thread_flag(TIF_SME))| WARN_ON(1);|| if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {| unsigned long vq_minus_one =| sve_vq_from_vl(task_get_sme_vl(current)) - 1;| sme_set_vq(vq_minus_one);|| fpsimd_bind_task_to_cpu();| }|| put_cpu_fpsimd_context();|| // Preempted; migrated from CPU 1 to CPU 0.| // task->fpsimd_cpu is still 0| // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:| // - Stale HW state is reused (with SME traps enabled)| // - TIF_FOREIGN_FPSTATE is cleared| // - A return to userspace skips HW state restore| }Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is setby calling fpsimd_flush_task_state() to detach from the saved CPUstate. This ensures that a subsequent context switch will not reuse thestale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing thenew state to be reloaded from memory prior to a return to userspace.Note: this was originallly posted as [1].[ Rutland: rewrite commit message ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39751 Severity: Moderate CVSS3 score: 4.5

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2021-3521 Severity: Moderate CVSS3 score: 4.4

Description: There is a flaw in RPM's signature functionality. OpenPGP subkeys are associated with a primary key via a "binding signature." RPM does not check the binding signature of subkeys prior to importing them. If an attacker is able to add or socially engineer another party to add a malicious subkey to a legitimate public key, RPM could wrongly trust a malicious signature. The greatest impact of this flaw is to data integrity. To exploit this flaw, an attacker must either compromise an RPM repository or convince an administrator to install an untrusted RPM or public key. It is strongly recommended to only use RPMs and public keys from trusted sources.

Packages affected:

librpmbuild10 > 0-0 (version in image is 4.20.1-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2024-50162 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: devmap: provide rxq after redirectrxq contains a pointer to the device from wherethe redirect happened. Currently, the BPF programthat was executed after a redirect via BPF_MAP_TYPE_DEVMAP*does not have it set.This is particularly bad since accessing ingress_ifindex, e.g.SEC("xdp")int prog(struct xdp_md *pkt){ return bpf_redirect_map(&dev_redirect_map, 0, 0);}SEC("xdp/devmap")int prog_after_redirect(struct xdp_md *pkt){ bpf_printk("ifindex %i", pkt->ingress_ifindex); return XDP_PASS;}depends on access to rxq, so a NULL pointer gets dereferenced:<1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000<1>[ 574.475188] #PF: supervisor read access in kernel mode<1>[ 574.475194] #PF: error_code(0x0000) - not-present page<6>[ 574.475199] PGD 0 P4D 0<4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23<4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023<4>[ 574.475231] Workqueue: mld mld_ifc_work<4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c<4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b<4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206<4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000<4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0<4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001<4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000<4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000<4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000<4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0<4>[ 574.475303] PKRU: 55555554<4>[ 574.475306] Call Trace:<4>[ 574.475313] <4>[ 574.475318] ? __die+0x23/0x70<4>[ 574.475329] ? page_fault_oops+0x180/0x4c0<4>[ 574.475339] ? skb_pp_cow_data+0x34c/0x490<4>[ 574.475346] ? kmem_cache_free+0x257/0x280<4>[ 574.475357] ? exc_page_fault+0x67/0x150<4>[ 574.475368] ? asm_exc_page_fault+0x26/0x30<4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c<4>[ 574.475386] bq_xmit_all+0x158/0x420<4>[ 574.475397] __dev_flush+0x30/0x90<4>[ 574.475407] veth_poll+0x216/0x250 [veth]<4>[ 574.475421] __napi_poll+0x28/0x1c0<4>[ 574.475430] net_rx_action+0x32d/0x3a0<4>[ 574.475441] handle_softirqs+0xcb/0x2c0<4>[ 574.475451] do_softirq+0x40/0x60<4>[ 574.475458] <4>[ 574.475461] <4>[ 574.475464] __local_bh_enable_ip+0x66/0x70<4>[ 574.475471] __dev_queue_xmit+0x268/0xe40<4>[ 574.475480] ? selinux_ip_postroute+0x213/0x420<4>[ 574.475491] ? alloc_skb_with_frags+0x4a/0x1d0<4>[ 574.475502] ip6_finish_output2+0x2be/0x640<4>[ 574.475512] ? nf_hook_slow+0x42/0xf0<4>[ 574.475521] ip6_finish_output+0x194/0x300<4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10<4>[ 574.475538] mld_sendpack+0x17c/0x240<4>[ 574.475548] mld_ifc_work+0x192/0x410<4>[ 574.475557] process_one_work+0x15d/0x380<4>[ 574.475566] worker_thread+0x29d/0x3a0<4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10<4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10<4>[ 574.475587] kthread+0xcd/0x100<4>[ 574.475597] ? __pfx_kthread+0x10/0x10<4>[ 574.475606] ret_from_fork+0x31/0x50<4>[ 574.475615] ? __pfx_kthread+0x10/0x10<4>[ 574.475623] ret_from_fork_asm+0x1a/0x---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-22870 Severity: Moderate CVSS3 score: 4.4

Description: Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to "*.example.com", a request to "[::1%25.example.com]:80` will incorrectly match and not be proxied.

Packages affected:

podman > 0-0 (version in image is 5.4.2-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38034 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: correct the order of prelim_ref arguments in btrfs__prelim_refbtrfs_prelim_ref() calls the old and new reference variables in theincorrect order. This causes a NULL pointer dereference because oldrefis passed as NULL to trace_btrfs_prelim_ref_insert().Note, trace_btrfs_prelim_ref_insert() is being called with newref asoldref (and oldref as NULL) on purpose in order to print outthe values of newref.To reproduce:echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enablePerform 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: 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38135 Severity: Moderate CVSS3 score: 4.4

Description: 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 pointerdereference.Add NULL check after devm_ioremap() to prevent this issue.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38153 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: aqc111: fix error handling of usbnet read callsSyzkaller, courtesy of syzbot, identified an error (see report [1]) inaqc111 driver, caused by incomplete sanitation of usb read calls'results. This problem is quite similar to the one fixed in commit920a9fa27e78 ("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 leadto MAC address in aqc111_bind() being only partly initialized,triggering KMSAN warnings.Fix the issue by verifying that the number of bytes read isas 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38156 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init()devm_ioremap() returns NULL on error. Currently, mt7996_mmio_wed_init()does not check for this case, which results in a NULL pointerdereference.Prevent null pointer dereference in mt7996_mmio_wed_init()

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38215 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_varIf fb_add_videomode() in do_register_framebuffer() fails to allocatememory for fb_videomode, it will later lead to a null-ptr dereference infb_videomode_to_var(), as the fb_info is registered while not having themode in modelist that is expected to be there, i.e. the one that isdescribed in fb_info->var.================================================================general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901Call 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() invar_to_display() fails, it can not prevent the panic because fbcon_init()does not return error code. Considering this and the comment in the codeabout fb_match_mode() returning NULL - "This should not happen" - it isbetter to prevent registering the fb_info if its mode was not setsuccessfully. Also move fb_add_videomode() closer to the beginning ofdo_register_framebuffer() to avoid having to do the cleanup on fail.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38229 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:media: cxusb: no longer judge rbuf when the write failssyzbot 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 therbuf.In this case, although rlen is 1, the write operation failed which resultedin the dvb read operation not being executed, and ultimately variable i wasnot 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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38256 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/rsrc: fix folio unpinningsyzbot complains about an unmapping failure:[ 108.070381][ T14] kernel BUG at mm/gup.c:71![ 108.070502][ T14] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP[ 108.123672][ T14] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250221-8.fc42 02/21/2025[ 108.127458][ T14] Workqueue: iou_exit io_ring_exit_work[ 108.174205][ T14] Call trace:[ 108.175649][ T14] sanity_check_pinned_pages+0x7cc/0x7d0 (P)[ 108.178138][ T14] unpin_user_page+0x80/0x10c[ 108.180189][ T14] io_release_ubuf+0x84/0xf8[ 108.182196][ T14] io_free_rsrc_node+0x250/0x57c[ 108.184345][ T14] io_rsrc_data_free+0x148/0x298[ 108.186493][ T14] io_sqe_buffers_unregister+0x84/0xa0[ 108.188991][ T14] io_ring_ctx_free+0x48/0x480[ 108.191057][ T14] io_ring_exit_work+0x764/0x7d8[ 108.193207][ T14] process_one_work+0x7e8/0x155c[ 108.195431][ T14] worker_thread+0x958/0xed8[ 108.197561][ T14] kthread+0x5fc/0x75c[ 108.199362][ T14] ret_from_fork+0x10/0x20We can pin a tail page of a folio, but then io_uring will try to unpinthe head page of the folio. While it should be fine in terms of keepingthe page actually alive, mm folks say it's wrong and triggers a debugwarning. Use unpin_user_folio() instead of unpin_user_page*.[axboe: adapt to current tree, massage commit message]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38274 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:fpga: fix potential null pointer deref in fpga_mgr_test_img_load_sgt()fpga_mgr_test_img_load_sgt() allocates memory for sgt usingkunit_kzalloc() however it does not check if the allocation failed.It then passes sgt to sg_alloc_table(), which passes it to__sg_alloc_table(). This function calls memset() on sgt in an attempt tozero it out. If the allocation fails then sgt will be NULL and thememset will trigger a NULL pointer dereference.Fix this by checking the allocation with KUNIT_ASSERT_NOT_ERR_OR_NULL().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38312 Severity: Moderate CVSS3 score: 4.4

Description: 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'sthen passed to fb_cvt_hperiod(), where it's used as a divider -- divisionby 0 will result in kernel oops. Add a sanity check for cvt.f_refresh toavoid such overflow...Found by Linux Verification Center (linuxtesting.org) with the Svace staticanalysis tool.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38317 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Fix buffer overflow in debugfsIf the user tries to write more than 32 bytes then it results in memorycorruption. Fortunately, this is debugfs so it's limited to root users.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38318 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:perf: arm-ni: Fix missing platform_set_drvdata()Add missing platform_set_drvdata in arm_ni_probe(), otherwisecalling platform_get_drvdata() in remove returns NULL.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38321 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:smb: Log an error when close_all_cached_dirs failsUnder low-memory conditions, close_all_cached_dirs() can't move thedentries to a separate list to dput() them once the locks are dropped.This will result in a "Dentry still in use" error, so add an errormessage that makes it clear this is what happened:[ 495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries[ 495.281595] ------------[ cut here ]------------[ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs][ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0Also, bail out of looping through all tcons as soon as a singleallocation fails, since we're already in trouble, and kmalloc() attemptsfor subseqeuent tcons are likely to fail just like the first one did.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38342 Severity: Moderate CVSS3 score: 4.4

Description: 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, sothe property value requires at least '(index + 1) * sizeof(*ref)' bytesbut that can not be guaranteed by current OOB check, and may cause OOBfor malformed property.Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38345 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: fix acpi operand cache leak in dswstate.cACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732I found an ACPI cache leak in ACPI early termination and boot continuing case.When early termination occurs due to malicious ACPI table, Linux kernelterminates ACPI function and continues to boot process. While kernel terminatesACPI 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, butacpi_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) showsmemory locations of kernel functions in stack dump. Some malicious userscould use this information to neutralize kernel ASLR.I made a patch to fix ACPI operand cache leak.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38400 Severity: Moderate CVSS3 score: 4.4

Description: 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 innfs_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 warningis 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 0CPU: 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/2025Call Trace: 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) [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:727Modules 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:727Code: 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 00RSP: 0018:ffffc90003637b08 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8RDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001RBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00R13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000FS: 0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: 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/0x7fRIP: 0033:0x7fa1a6b8e929Code: 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---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38446 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:clk: imx: Fix an out-of-bounds access in dispmix_csr_clk_dev_dataWhen num_parents is 4, __clk_register() occurs an out-of-boundswhen accessing parent_names member. Use ARRAY_SIZE() instead ofhardcode number here. BUG: KASAN: global-out-of-bounds in __clk_register+0x1844/0x20d8 Read of size 8 at addr ffff800086988e78 by task kworker/u24:3/59 Hardware name: NXP i.MX95 19X19 board (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x8c/0xcc print_report+0x398/0x5fc kasan_report+0xd4/0x114 __asan_report_load8_noabort+0x20/0x2c __clk_register+0x1844/0x20d8 clk_hw_register+0x44/0x110 __clk_hw_register_mux+0x284/0x3a8 imx95_bc_probe+0x4f4/0xa70

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38454 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ad1816a: Fix potential NULL pointer deref in snd_card_ad1816a_pnp()Use pr_warn() instead of dev_warn() when 'pdev' is NULL to avoid apotential NULL pointer dereference.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38489 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL againCommit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") hasaccidentally removed the critical piece of commit c730fce7c70c("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), causingintermittent kernel panics in e.g. perf's on_switch() prog to reappear.Restore the fix and add a comment.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38508 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:x86/sev: Use TSC_FACTOR for Secure TSC frequency calculationWhen using Secure TSC, the GUEST_TSC_FREQ MSR reports a frequency based onthe nominal P0 frequency, which deviates slightly (typically ~0.2%) fromthe actual mean TSC frequency due to clocking parameters.Over extended VM uptime, this discrepancy accumulates, causing clock skewbetween the hypervisor and a SEV-SNP VM, leading to early timer interrupts asperceived by the guest.The guest kernel relies on the reported nominal frequency for TSC-basedtimekeeping, while the actual frequency set during SNP_LAUNCH_START maydiffer. This mismatch results in inaccurate time calculations, causing theguest to perceive hrtimers as firing earlier than expected.Utilize the TSC_FACTOR from the SEV firmware's secrets page (see "SecretsPage Format" in the SNP Firmware ABI Specification) to calculate the meanTSC frequency, ensuring accurate timekeeping and mitigating clock skew inSEV-SNP VMs.Use early_ioremap_encrypted() to map the secrets page asioremap_encrypted() uses kmalloc() which is not available during early TSCinitialization and causes a panic. [ bp: Drop the silly dummy var: https://lore.kernel.org/r/20250630192726.GBaGLlHl84xIopx4Pt@fat_crate.local ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38591 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject narrower access to pointer ctx fieldsThe following BPF program, simplified from a syzkaller repro, causes akernel warning: r0 = *(u8 *)(r1 + 169); exit;With pointer field sk being at offset 168 in __sk_buff. This access isdetected as a narrower read in bpf_skb_is_valid_access because itdoesn't match offsetof(struct __sk_buff, sk). It is therefore allowedand later proceeds to bpf_convert_ctx_access. Note that for the"is_narrower_load" case in the convert_ctx_accesses(), the insn->offis aligned, so the cnt may not be 0 because it matches theoffsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1)This patch fixes that to return a proper "invalid bpf_context accessoff=X size=Y" error on the load instruction.The same issue affects multiple other fields in context structures thatallow narrow access. Some other non-affected fields (for sk_msg,sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr forconsistency.Note this syzkaller crash was reported in the "Closes" link below, whichused to be about a different bug, fixed incommit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructionsin insn_def_regno()"). Because syzbot somehow confused the two bugs,the new crash and repro didn't get reported to the mailing list.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38692 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: add cluster chain loop check for dirAn infinite loop may occur if the following conditions occur due tofile system corruption.(1) Condition for exfat_count_dir_entries() to loop infinitely. - The cluster chain includes a loop. - There is no UNUSED entry in the cluster chain.(2) Condition for exfat_create_upcase_table() to loop infinitely. - The cluster chain of the root directory includes a loop. - There are no UNUSED entry and up-case table entry in the cluster chain of the root directory.(3) Condition for exfat_load_bitmap() to loop infinitely. - The cluster chain of the root directory includes a loop. - There are no UNUSED entry and bitmap entry in the cluster chain of the root directory.(4) Condition for exfat_find_dir_entry() to loop infinitely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation.(5) Condition for exfat_check_dir_empty() to loop infinitely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation. - All files and sub-directories under the directory are deleted.This commit adds checks to break the above infinite loop.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39706 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Destroy KFD debugfs after destroy KFD wqSince KFD proc content was moved to kernel debugfs, we can't destroy KFDdebugfs before kfd_process_destroy_wq. Move kfd_process_destroy_wq priorto kfd_debugfs_fini to fix a kernel NULL pointer problem. It happenswhen /sys/kernel/debug/kfd was already destroyed in kfd_debugfs_fini butkfd_process_destroy_wq calls kfd_debugfs_remove_process. This line debugfs_remove_recursive(entry->proc_dentry);tries to remove /sys/kernel/debug/kfd/proc/ while/sys/kernel/debug/kfd is already gone. It hangs the kernel by kernelNULL pointer.(cherry picked from commit 0333052d90683d88531558dcfdbf2525cc37c233)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39707 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: check if hubbub is NULL in debugfs/amdgpu_dm_capabilitiesHUBBUB structure is not initialized on DCE hardware, so check if it is NULLto avoid null dereference while accessing amdgpu_dm_capabilities file indebugfs.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39738 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not allow relocation of partially dropped subvolumes[BUG]There is an internal report that balance triggered transaction abort,with the following call trace: item 85 key (594509824 169 0) itemoff 12599 itemsize 33 extent refs 1 gen 197740 flags 2 ref#0: tree block backref root 7 item 86 key (594558976 169 0) itemoff 12566 itemsize 33 extent refs 1 gen 197522 flags 2 ref#0: tree block backref root 7 ... BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -117) WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]And btrfs check doesn't report anything wrong related to the extenttree.[CAUSE]The cause is a little complex, firstly the extent tree indeed doesn'thave the backref for 594526208.The extent tree only have the following two backrefs around that bytenron-disk: item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33 refs 1 gen 197740 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREE item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33 refs 1 gen 197522 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREEBut the such missing backref item is not an corruption on disk, as theoffending delayed ref belongs to subvolume 934, and that subvolume isbeing dropped: item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439 generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328 last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0 drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2 level 2 generation_v2 198229And that offending tree block 594526208 is inside the dropped range ofthat subvolume. That explains why there is no backref item for thatbytenr and why btrfs check is not reporting anything wrong.But this also shows another problem, as btrfs will do all the orphansubvolume cleanup at a read-write mount.So half-dropped subvolume should not exist after an RW mount, andbalance itself is also exclusive to subvolume cleanup, meaning weshouldn't hit a subvolume half-dropped during relocation.The root cause is, there is no orphan item for this subvolume.In fact there are 5 subvolumes from around 2021 that have the sameproblem.It looks like the original report has some older kernels running, andcaused those zombie subvolumes.Thankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshotdeletion not triggered on mount") has long fixed the bug.[ENHANCEMENT]For repairing such old fs, btrfs-progs will be enhanced.Considering how delayed the problem will show up (at run delayed reftime) and at that time we have to abort transaction already, it is toolate.Instead here we reject any half-dropped subvolume for reloc tree at theearliest time, preventing confusion and extra time wasted on debuggingsimilar bugs.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39763 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: APEI: send SIGBUS to current task if synchronous memory error not recoveredIf a synchronous error is detected as a result of user-space processtriggering a 2-bit uncorrected error, the CPU will take a synchronouserror exception such as Synchronous External Abort (SEA) on Arm64. Thekernel will queue a memory_failure() work which poisons the relatedpage, unmaps the page, and then sends a SIGBUS to the process, so thata system wide panic can be avoided.However, no memory_failure() work will be queued when abnormalsynchronous errors occur. These errors can include situations likeinvalid PA, unexpected severity, no memory failure config support,invalid GUID section, etc. In such a case, the user-space process willtrigger SEA again. This loop can potentially exceed the platformfirmware threshold or even trigger a kernel hard lockup, leading to asystem reboot.Fix it by performing a force kill if no memory_failure() work is queuedfor synchronous errors.[ rjw: Changelog edits ]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39787 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: mdt_loader: Ensure we don't read past the ELF headerWhen the MDT loader is used in remoteproc, the ELF header is sanitizedbeforehand, but that's not necessary the case for other clients.Validate the size of the firmware buffer to ensure that we don't readpast the end as we iterate over the header. e_phentsize and e_shentsizeare validated as well, to ensure that the assumptions about step size inthe traversal are valid.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39903 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:of_numa: fix uninitialized memory nodes causing kernel panicWhen there are memory-only nodes (nodes without CPUs), these nodes are notproperly initialized, causing kernel panic during boot.of_numa_init of_numa_parse_cpu_nodes node_set(nid, numa_nodes_parsed); of_numa_parse_memory_nodesIn of_numa_parse_cpu_nodes, numa_nodes_parsed gets updated only for nodescontaining CPUs. Memory-only nodes should have been updated inof_numa_parse_memory_nodes, but they weren't.Subsequently, when free_area_init() attempts to access NODE_DATA() forthese uninitialized memory nodes, the kernel panics due to NULL pointerdereference.This can be reproduced on ARM64 QEMU with 1 CPU and 2 memory nodes:qemu-system-aarch64 \-cpu host -nographic \-m 4G -smp 1 \-machine virt,accel=kvm,gic-version=3,iommu=smmuv3 \-object memory-backend-ram,size=2G,id=mem0 \-object memory-backend-ram,size=2G,id=mem1 \-numa node,nodeid=0,memdev=mem0 \-numa node,nodeid=1,memdev=mem1 \-kernel $IMAGE \-hda $DISK \-append "console=ttyAMA0 root=/dev/vda rw earlycon"[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x481fd010][ 0.000000] Linux version 6.17.0-rc1-00001-gabb4b3daf18c-dirty (yintirui@local) (gcc (GCC) 12.3.1, GNU ld (GNU Binutils) 2.41) #52 SMP PREEMPT Mon Aug 18 09:49:40 CST 2025[ 0.000000] KASLR enabled[ 0.000000] random: crng init done[ 0.000000] Machine model: linux,dummy-virt[ 0.000000] efi: UEFI not found.[ 0.000000] earlycon: pl11 at MMIO 0x0000000009000000 (options '')[ 0.000000] printk: legacy bootconsole [pl11] enabled[ 0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT[ 0.000000] NODE_DATA(0) allocated [mem 0xbfffd9c0-0xbfffffff][ 0.000000] node 1 must be removed before remove section 23[ 0.000000] Zone ranges:[ 0.000000] DMA [mem 0x0000000040000000-0x00000000ffffffff][ 0.000000] DMA32 empty[ 0.000000] Normal [mem 0x0000000100000000-0x000000013fffffff][ 0.000000] Movable zone start for each node[ 0.000000] Early memory node ranges[ 0.000000] node 0: [mem 0x0000000040000000-0x00000000bfffffff][ 0.000000] node 1: [mem 0x00000000c0000000-0x000000013fffffff][ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x00000000bfffffff][ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0[ 0.000000] Mem abort info:[ 0.000000] ESR = 0x0000000096000004[ 0.000000] EC = 0x25: DABT (current EL), IL = 32 bits[ 0.000000] SET = 0, FnV = 0[ 0.000000] EA = 0, S1PTW = 0[ 0.000000] FSC = 0x04: level 0 translation fault[ 0.000000] Data abort info:[ 0.000000] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 0.000000] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 0.000000] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 0.000000] [00000000000000a0] user address but active_mm is swapper[ 0.000000] Internal error: Oops: 0000000096000004 [#1] SMP[ 0.000000] Modules linked in:[ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.17.0-rc1-00001-g760c6dabf762-dirty #54 PREEMPT[ 0.000000] Hardware name: linux,dummy-virt (DT)[ 0.000000] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 0.000000] pc : free_area_init+0x50c/0xf9c[ 0.000000] lr : free_area_init+0x5c0/0xf9c[ 0.000000] sp : ffffa02ca0f33c00[ 0.000000] x29: ffffa02ca0f33cb0 x28: 0000000000000000 x27: 0000000000000000[ 0.000000] x26: 4ec4ec4ec4ec4ec5 x25: 00000000000c0000 x24: 00000000000c0000[ 0.000000] x23: 0000000000040000 x22: 0000000000000000 x21: ffffa02ca0f3b368[ 0.000000] x20: ffffa02ca14c7b98 x19: 0000000000000000 x18: 0000000000000002[ 0.000000] x17: 000000000000cacc x16: 0000000000000001 x15: 0000000000000001[ 0.000000] x14: 0000000080000000 x13: 0000000000000018 x12: 0000000000000002[ 0.0---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39917 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix out-of-bounds dynptr write in bpf_crypto_cryptStanislav reported that in bpf_crypto_crypt() the destination dynptr'ssize is not validated to be at least as large as the source dynptr'ssize before calling into the crypto backend with 'len = src_len'. Thiscan result in an OOB write when the destination is smaller than thesource.Concretely, in mentioned function, psrc and pdst are both linearbuffers fetched from each dynptr: psrc = __bpf_dynptr_data(src, src_len); [...] pdst = __bpf_dynptr_data_rw(dst, dst_len); [...] err = decrypt ? ctx->type->decrypt(ctx->tfm, psrc, pdst, src_len, piv) : ctx->type->encrypt(ctx->tfm, psrc, pdst, src_len, piv);The crypto backend expects pdst to be large enough with a src_len lengththat can be written. Add an additional src_len > dst_len check and bailout if it's the case. Note that these kfuncs are accessible under rootprivileges only.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39958 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/s390: Make attach succeed when the device was surprise removedWhen a PCI device is removed with surprise hotplug, there may still beattempts to attach the device to the default domain as part of tear downvia (__iommu_release_dma_ownership()), or because the removal happensduring probe (__iommu_probe_device()). In both cases zpci_register_ioat()fails with a cc value indicating that the device handle is invalid. Thisis because the device is no longer part of the instance as far as thehypervisor is concerned.Currently this leads to an error return and s390_iommu_attach_device()fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()because attaching to the default domain must never fail.With the device fenced by the hypervisor no DMAs to or from memory arepossible and the IOMMU translations have no effect. Proceed as if theregistration was successful and let the hotplug event handling clean upthe device.This is similar to how devices in the error state are handled sincecommit 59bbf596791b ("iommu/s390: Make attach succeed even if the deviceis in error state") except that for removal the domain will not beregistered later. This approach was also previously discussed at thelink.Handle both cases, error state and removal, in a helper which checks ifthe error needs to be propagated or ignored. Avoid magic numbercondition codes by using the pre-existing, but never used, defines forPCI load/store condition codes and rename them to reflect that theyapply to all PCI instructions.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-39969 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix validation of VF state in get resourcesVF state I40E_VF_STATE_ACTIVE is not the only state in whichVF is actually active so it should not be used to determineif a VF is allowed to obtain resources.Use I40E_VF_STATE_RESOURCES_LOADED that is set only ini40e_vc_get_vf_resources_msg() and cleared during reset.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39980 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:nexthop: Forbid FDB status change while nexthop is in a groupThe kernel forbids the creation of non-FDB nexthop groups with FDBnexthops: # ip nexthop add id 1 via 192.0.2.1 fdb # ip nexthop add id 2 group 1 Error: Non FDB nexthop group cannot have fdb nexthops.And vice versa: # ip nexthop add id 3 via 192.0.2.2 dev dummy1 # ip nexthop add id 4 group 3 fdb Error: FDB nexthop group can only have fdb nexthops.However, as long as no routes are pointing to a non-FDB nexthop group,the kernel allows changing the type of a nexthop from FDB to non-FDB andvice versa: # ip nexthop add id 5 via 192.0.2.2 dev dummy1 # ip nexthop add id 6 group 5 # ip nexthop replace id 5 via 192.0.2.2 fdb # echo $? 0This configuration is invalid and can result in a NPD [1] since FDBnexthops are not associated with a nexthop device: # ip route add 198.51.100.1/32 nhid 6 # ping 198.51.100.1Fix by preventing nexthop FDB status change while the nexthop is in agroup: # ip nexthop add id 7 via 192.0.2.2 dev dummy1 # ip nexthop add id 8 group 7 # ip nexthop replace id 7 via 192.0.2.2 fdb Error: Cannot change nexthop FDB status while in a group.[1]BUG: kernel NULL pointer dereference, address: 00000000000003c0[...]Oops: Oops: 0000 [#1] SMPCPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014RIP: 0010:fib_lookup_good_nhc+0x1e/0x80[...]Call Trace: fib_table_lookup+0x541/0x650 ip_route_output_key_hash_rcu+0x2ea/0x970 ip_route_output_key_hash+0x55/0x80 __ip4_datagram_connect+0x250/0x330 udp_connect+0x2b/0x60 __sys_connect+0x9c/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0xa4/0x2a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40021 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40032 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before releaseThe fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can beNULL even after EPF initialization. Then it is prudent to check thatthey have non-NULL values before releasing the channels. Add the checksin pci_epf_test_clean_dma_chan().Without the checks, NULL pointer dereferences happen and they can leadto a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20[mani: trimmed the stack trace]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40136 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/qm - request reserved interrupt for virtual functionThe device interrupt vector 3 is an error interrupt forphysical function and a reserved interrupt for virtual function.However, the driver has not registered the reserved interrupt forvirtual function. When allocating interrupts, the number of interruptsis allocated based on powers of two, which includes this interrupt.When the system enables GICv4 and the virtual function passthroughto the virtual machine, releasing the interrupt in the drivertriggers a warning.The WARNING report is:WARNING: CPU: 62 PID: 14889 at arch/arm64/kvm/vgic/vgic-its.c:852 its_free_ite+0x94/0xb4Therefore, register a reserved interrupt for VF and set theIRQF_NO_AUTOEN flag to avoid that warning.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40144 Severity: Moderate CVSS3 score: 4.4

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40178 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:pid: Add a judgment for ns null in pid_nr_ns__task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) {Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40255 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()The ethtool tsconfig Netlink path can trigger a null pointerdereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower()results in generic_hwtstamp_ioctl_lower() being called withkernel_cfg->ifr as NULL.The generic_hwtstamp_ioctl_lower() function does not expecta NULL ifr and dereferences it, leading to a system crash.Fix this by adding a NULL check for kernel_cfg->ifr ingeneric_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40279 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_connmark: initialize struct tc_ife to fix kernel leakIn tcf_connmark_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40293 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: Don't overflow during division for dirty trackingIf pgshift is 63 then BITS_PER_TYPE(*bitmap->bitmap) * pgsize will overflowto 0 and this triggers divide by 0.In this case the index should just be 0, so reorganize things to divideby shift and avoid hitting any overflows.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40294 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()In the parse_adv_monitor_pattern() function, the value ofthe 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251).The size of the 'value' array in the mgmt_adv_pattern structure is 31.If the value of 'pattern[i].length' is set in the user spaceand exceeds 31, the 'patterns[i].value' array can be accessedout of bound when copied.Increasing the size of the 'value' array inthe 'mgmt_adv_pattern' structure will break the userspace.Considering this, and to avoid OOB access revert the limits for 'offset'and 'length' back to the value of HCI_MAX_AD_LENGTH.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40301 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: validate skb length for unknown CC opcodeIn hci_cmd_complete_evt(), if the command complete event has an unknownopcode, we assume the first byte of the remaining skb->data contains thereturn status. However, parameter data has previously been pulled inhci_event_func(), which may leave the skb empty. If so, using skb->data[0]for the return status uses un-init memory.The fix is to check skb->len before using skb->data.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40339 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix nullptr err of vm_handle_movedIf a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL.So, such kind of amdgpu_bo_va should be updated separately beforeamdgpu_vm_handle_moved.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68286 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check NULL before accessing[WHAT]IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomicfails with NULL pointer dereference. This can be reproduced withboth an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ...(cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68744 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Free special fields when update [lru_,]percpu_hash mapsAs [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missingcalls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause thememory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until themap gets freed.Fix this by calling 'bpf_obj_free_fields()' after'copy_map_value[,_long]()' in 'pcpu_copy_value()'.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-68764 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flagsWhen a filesystem is being automounted, it needs to preserve theuser-set superblock mount options, such as the "ro" flag.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71091 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:team: fix check for port enabled in team_queue_override_port_prio_changed()There has been a syzkaller bug reported recently with the followingtrace:list_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122)------------[ cut here ]------------kernel BUG at lib/list_debug.c:59!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ffRSP: 0018:ffffc9000d49f370 EFLAGS: 00010286RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0Call Trace: __list_del_entry_valid include/linux/list.h:132 [inline] __list_del_entry include/linux/list.h:223 [inline] list_del_rcu include/linux/rculist.h:178 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net/team/team_core.c:376 [inline] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684 __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe problem is in this flow:1) Port is enabled, queue_id != 0, in qom_list2) Port gets disabled -> team_port_disable() -> team_queue_override_port_del() -> del (removed from list)3) Port is disabled, queue_id != 0, not in any list4) Priority changes -> team_queue_override_port_prio_changed() -> checks: port disabled && queue_id != 0 -> calls del - hits the BUG as it is removed alreadyTo fix this, change the check in team_queue_override_port_prio_changed()so it returns early if port is not enabled.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23042 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix aux device unplugging when rdma is not supported by vportIf vport flags do not contain VIRTCHNL2_VPORT_ENABLE_RDMA, driver does notallocate vdev_info for this vport. This leads to kernel NULL pointerdereference in idpf_idc_vport_dev_down(), which references vdev_info forevery vport regardless.Check, if vdev_info was ever allocated before unplugging aux device.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23064 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_ife: avoid possible NULL dereftcf_ife_encode() must make sure ife_encode() does not return NULL.syzbot reported:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full)Call Trace: ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [inline] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [inline] tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [inline] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [inline] __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23108 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leakFix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:gs_usb_receive_bulk_callback(): fix URB memory leak").In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers areallocated, added to the priv->rx_submitted anchor and submitted. In thecomplete callback usb_8dev_read_bulk_callback(), the URBs are processed andresubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed bycalling usb_kill_anchored_urbs(&priv->rx_submitted).However, this does not take into account that the USB framework unanchorsthe URB before the complete function is called. This means that once anin-URB has been completed, it is no longer anchored and is ultimately notreleased in usb_kill_anchored_urbs().Fix the memory leak by anchoring the URB in theusb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-0725 Severity: Moderate CVSS3 score: 4.3

Description: When libcurl is asked to perform automatic gzip decompression ofcontent-encoded HTTP responses with the `CURLOPT_ACCEPT_ENCODING` option,**using zlib 1.2.0.3 or older**, an attacker-controlled integer overflow wouldmake libcurl perform a buffer overflow.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
curl > 0-0 (version in image is 8.14.1-160000.2.2).

CVE-2025-12084 Severity: Moderate CVSS3 score: 4.3

Description: When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpython3_13-1_0 < 3.13.11-160000.1.1 (version in image is 3.13.5-160000.2.2).

CVE-2025-39918 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: fix linked list corruptionNever leave scheduled wcid entries on the temporary on-stack list

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39948 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix Rx page leak on multi-buffer framesThe ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for eachbuffer in the current frame. This function was introduced as part ofhandling multi-buffer XDP support in the ice driver.It works by iterating over the buffers from first_desc up to 1 plus thetotal number of fragments in the frame, cached from before the XDP programwas executed.If the hardware posts a descriptor with a size of 0, the logic used inice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get addedas fragments in ice_add_xdp_frag. Since the buffer isn't counted as afragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don'tcall ice_put_rx_buf().Because we don't call ice_put_rx_buf(), we don't attempt to re-use thepage or free it. This leaves a stale page in the ring, as we don'tincrement next_to_alloc.The ice_reuse_rx_page() assumes that the next_to_alloc has been incrementedproperly, and that it always points to a buffer with a NULL page. Sincethis function doesn't check, it will happily recycle a page over the topof the next_to_alloc buffer, losing track of the old page.Note that this leak only occurs for multi-buffer frames. Theice_put_rx_mbuf() function always handles at least one buffer, so asingle-buffer frame will always get handled correctly. It is not clearprecisely why the hardware hands us descriptors with a size of 0 sometimes,but it happens somewhat regularly with "jumbo frames" used by 9K MTU.To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() onall buffers between first_desc and next_to_clean. Borrow the logic of asimilar function in i40e used for this same purpose. Use the same logicalso in ice_get_pgcnts().Instead of iterating over just the number of fragments, use a loop whichiterates until the current index reaches to the next_to_clean element justpast the current frame. Unlike i40e, the ice_put_rx_mbuf() function doescall ice_put_rx_buf() on the last buffer of the frame indicating the end ofpacket.For non-linear (multi-buffer) frames, we need to take care when adjustingthe pagecnt_bias. An XDP program might release fragments from the tail ofthe frame, in which case that fragment page is already released. Onlyupdate the pagecnt_bias for the first descriptor and fragments stillremaining post-XDP program. Take care to only access the shared info forfragmented buffers, as this avoids a significant cache miss.The xdp_xmit value only needs to be updated if an XDP program is run, andonly once per packet. Drop the xdp_xmit pointer argument fromice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() functiondirectly. This avoids needing to pass the argument and avoids an extrabit-wise OR for each buffer in the frame.Move the increment of the ntc local variable to ensure its updated *before*all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logicrequires the index of the element just after the current frame.Now that we use an index pointer in the ring to identify the packet, we nolonger need to track or cache the number of fragments in the rx_ring.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-55193 Severity: Moderate CVSS3 score: 4.3

Description: Active Record connects classes to relational database tables. Prior to versions 7.1.5.2, 7.2.2.2, and 8.0.2.1, the ID passed to find or similar methods may be logged without escaping. If this is directly to the terminal it may include unescaped ANSI sequences. This issue has been patched in versions 7.1.5.2, 7.2.2.2, and 8.0.2.1.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
hawk2 < 2.7.0+git.1742310530.bfcd0e2c-160000.3.1 (version in image is 2.7.0+git.1742310530.bfcd0e2c-160000.2.2).

CVE-2026-21441 Severity: Moderate CVSS3 score: 4.3

Description: urllib3 is an HTTP client library for Python. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. urllib3 can perform decoding or decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API, the library decompresses only the necessary bytes, enabling partial content consumption. Starting in version 1.22 and prior to version 2.6.3, for HTTP redirect responses, the library would read the entire response body to drain the connection and decompress the content unnecessarily. This decompression occurred even before any read methods were called, and configured read limits did not restrict the amount of decompressed data. As a result, there was no safeguard against decompression bombs. A malicious server could exploit this to trigger excessive resource consumption on the client. Applications and libraries are affected when they stream content from untrusted sources by setting `preload_content=False` when they do not disable redirects. Users should upgrade to at least urllib3 v2.6.3, in which the library does not decode content of redirect responses when `preload_content=False`. If upgrading is not immediately possible, disable redirects by setting `redirect=False` for requests to untrusted source.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313-urllib3 < 2.5.0-160000.3.1 (version in image is 2.5.0-160000.2.2).

CVE-2021-37577 Severity: Moderate CVSS3 score: 4.2

Description: Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple Pairing using the Passkey entry protocol in Bluetooth Core Specifications 2.1 through 5.3 may permit an unauthenticated man-in-the-middle attacker to identify the Passkey used during pairing by reflection of a crafted public key with the same X coordinate as the offered public key and by reflection of the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. This is a related issue to CVE-2020-26558.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2024-12224 Severity: Moderate CVSS3 score: 4.2

Description: Improper Validation of Unsafe Equivalence in punycode by the idna crate from Servo rust-url allows an attacker to create a punycode hostname that one part of a system might treat as distinct while another part of that system would treat as equivalent to another hostname.

Packages affected:

gdk-pixbuf-loader-rsvg > 0-0 (version in image is 2.60.0-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2024-46680 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btnxpuart: Fix random crash seen while removing driverThis fixes the random kernel crash seen while removing the driver, whenrunning the load/unload test over multiple iterations.1) modprobe btnxpuart2) hciconfig hci0 reset3) hciconfig (check hci0 interface up with valid BD address)4) modprobe -r btnxpuartRepeat steps 1 to 4The ps_wakeup() call in btnxpuart_close() schedules the psdata->work(),which gets scheduled after module is removed, causing a kernel crash.This hidden issue got highlighted after enabling Power Save by defaultin 4183a7be7700 (Bluetooth: btnxpuart: Enable Power Save feature onstartup)The new ps_cleanup() deasserts UART break immediately while closingserdev device, cancels any scheduled ps_work and destroys the ps_lockmutex.[ 85.884604] Unable to handle kernel paging request at virtual address ffffd4a61638f258[ 85.884624] Mem abort info:[ 85.884625] ESR = 0x0000000086000007[ 85.884628] EC = 0x21: IABT (current EL), IL = 32 bits[ 85.884633] SET = 0, FnV = 0[ 85.884636] EA = 0, S1PTW = 0[ 85.884638] FSC = 0x07: level 3 translation fault[ 85.884642] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041dd0000[ 85.884646] [ffffd4a61638f258] pgd=1000000095fff003, p4d=1000000095fff003, pud=100000004823d003, pmd=100000004823e003, pte=0000000000000000[ 85.884662] Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP[ 85.890932] Modules linked in: algif_hash algif_skcipher af_alg overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_spdif snd_soc_fsl_micfil snd_soc_fsl_sai snd_soc_fsl_utils gpio_ir_recv rc_core fuse [last unloaded: btnxpuart(O)][ 85.927297] CPU: 1 PID: 67 Comm: kworker/1:3 Tainted: G O 6.1.36+g937b1be4345a #1[ 85.936176] Hardware name: FSL i.MX8MM EVK board (DT)[ 85.936182] Workqueue: events 0xffffd4a61638f380[ 85.936198] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 85.952817] pc : 0xffffd4a61638f258[ 85.952823] lr : 0xffffd4a61638f258[ 85.952827] sp : ffff8000084fbd70[ 85.952829] x29: ffff8000084fbd70 x28: 0000000000000000 x27: 0000000000000000[ 85.963112] x26: ffffd4a69133f000 x25: ffff4bf1c8540990 x24: ffff4bf215b87305[ 85.963119] x23: ffff4bf215b87300 x22: ffff4bf1c85409d0 x21: ffff4bf1c8540970[ 85.977382] x20: 0000000000000000 x19: ffff4bf1c8540880 x18: 0000000000000000[ 85.977391] x17: 0000000000000000 x16: 0000000000000133 x15: 0000ffffe2217090[ 85.977399] x14: 0000000000000001 x13: 0000000000000133 x12: 0000000000000139[ 85.977407] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff8000084fbc50[ 85.977417] x8 : ffff4bf215b7d000 x7 : ffff4bf215b83b40 x6 : 00000000000003e8[ 85.977424] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000000[ 85.977432] x2 : 0000000000000000 x1 : ffff4bf1c4265880 x0 : 0000000000000000[ 85.977443] Call trace:[ 85.977446] 0xffffd4a61638f258[ 85.977451] 0xffffd4a61638f3e8[ 85.977455] process_one_work+0x1d4/0x330[ 85.977464] worker_thread+0x6c/0x430[ 85.977471] kthread+0x108/0x10c[ 85.977476] ret_from_fork+0x10/0x20[ 85.977488] Code: bad PC value[ 85.977491] ---[ end trace 0000000000000000 ]---Preset since v6.9.11

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-37861 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queueWhen the task management thread processes reply queues while the resetthread resets them, the task management thread accesses an invalid queue ID(0xFFFF), set by the reset thread, which points to unallocated memory,causing a crash.Add flag 'io_admin_reset_sync' to synchronize access between the reset,I/O, and admin threads. Before a reset, the reset handler sets this flag toblock I/O and admin processing threads. If any thread bypasses the initialcheck, the reset thread waits up to 10 seconds for processing to finish. Ifthe wait exceeds 10 seconds, the controller is marked as unrecoverable.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38038 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: amd-pstate: Remove unnecessary driver_lock in set_boostset_boost is a per-policy function call, hence a driver wide lock isunnecessary. Also this mutex_acquire can collide with the mutex_acquirefrom the mode-switch path in status_store(), which can lead to adeadlock. So, remove it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38232 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: fix race between nfsd registration and exports_procAs of now nfsd calls create_proc_exports_entry() at start of init_nfsdand cleanup by remove_proc_entry() at last of exit_nfsd.Which causes kernel OOPs if there is race between below 2 operations:(i) exportfs -r(ii) mount -t nfsd none /proc/fs/nfsdfor 5.4 kernel ARM64:CPU 1:el1_irq+0xbc/0x180arch_counter_get_cntvct+0x14/0x18running_clock+0xc/0x18preempt_count_add+0x88/0x110prep_new_page+0xb0/0x220get_page_from_freelist+0x2d8/0x1778__alloc_pages_nodemask+0x15c/0xef0__vmalloc_node_range+0x28c/0x478__vmalloc_node_flags_caller+0x8c/0xb0kvmalloc_node+0x88/0xe0nfsd_init_net+0x6c/0x108 [nfsd]ops_init+0x44/0x170register_pernet_operations+0x114/0x270register_pernet_subsys+0x34/0x50init_nfsd+0xa8/0x718 [nfsd]do_one_initcall+0x54/0x2e0CPU 2 :Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010PC is at : exports_net_open+0x50/0x68 [nfsd]Call trace:exports_net_open+0x50/0x68 [nfsd]exports_proc_open+0x2c/0x38 [nfsd]proc_reg_open+0xb8/0x198do_dentry_open+0x1c4/0x418vfs_open+0x38/0x48path_openat+0x28c/0xf18do_filp_open+0x70/0xe8do_sys_open+0x154/0x248Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().and same is happening on latest 6.14 kernel as well:[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty...[ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48...[ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4...[ 285.469695] Call trace:[ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P)[ 285.470488] seq_read+0xe0/0x11c[ 285.470675] proc_reg_read+0x9c/0xf0[ 285.470874] vfs_read+0xc4/0x2fc[ 285.471057] ksys_read+0x6c/0xf4[ 285.471231] __arm64_sys_read+0x1c/0x28[ 285.471428] invoke_syscall+0x44/0x100[ 285.471633] el0_svc_common.constprop.0+0x40/0xe0[ 285.471870] do_el0_svc_compat+0x1c/0x34[ 285.472073] el0_svc_compat+0x2c/0x80[ 285.472265] el0t_32_sync_handler+0x90/0x140[ 285.472473] el0t_32_sync+0x19c/0x1a0[ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3)[ 285.473422] ---[ end trace 0000000000000000 ]---It reproduced simply with below script:while [ 1 ]do/exportfs -rdone &while [ 1 ]doinsmod /nfsd.komount -t nfsd none /proc/fs/nfsdumount /proc/fs/nfsdrmmod nfsddone &So exporting interfaces to user space shall be done at last andcleanup at first place.With change there is no Kernel OOPs.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38336 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330The controller has a hardware bug that can hard hang the system whendoing ATAPI DMAs without any trace of what happened. Depending on thedevice attached, it can also prevent the system from booting.In this case, the system hangs when reading the ATIP from optical mediawith cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and anOptiarc 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 cygwinbuild of cdrecord on WinXP, although it requires more attempts to causeit. The hang in that case is also resolved by forcing PIO. It doesn'tappear that VIA has produced any drivers for that OS, thus no knownworkaround exists.HDDs attached to the controller do not suffer from any DMA issues.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38382 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix iteration of extrefs during log replayAt __inode_add_ref() when processing extrefs, if we jump into the nextlabel we have an undefined value of victim_name.len, since we haven'tinitialized it before we did the goto. This results in an invalid memoryaccess in the next iteration of the loop since victim_name.len was notinitialized to the length of the name of the current extref.Fix this by initializing victim_name.len with the current extref's namelength.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39947 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Harden uplink netdev access against device unbindThe function mlx5_uplink_netdev_get() gets the uplink netdevicepointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice canbe removed and its pointer cleared when unbound from the mlx5_core.ethdriver. This results in a NULL pointer, causing a kernel panic. BUG: unable to handle page fault for address: 0000000000001300 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core] Call Trace: mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core] esw_offloads_enable+0x593/0x910 [mlx5_core] mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xd0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x183/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 do_syscall_64+0x53/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53Ensure the pointer is valid before use by checking it for NULL. If itis valid, immediately call netdev_hold() to take a reference, andpreventing the netdevice from being freed while it is in use.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40110 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix a null-ptr access in the cursor snooperCheck that the resource which is converted to a surface exists beforetrying to use the cursor snooper on it.vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiersbecause some svga commands accept SVGA3D_INVALID_ID to mean "no surface",unfortunately functions that accept the actual surfaces as objects might(and in case of the cursor snooper, do not) be able to handle nullobjects. Make sure that we validate not only the identifier (via thevmw_cmd_res_check) but also check that the actual resource exists beforetrying to do something with it.Fixes unchecked null-ptr reference in the snooping code.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40187 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce()If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0and sctp_ulpevent_make_authkey() returns 0, then the variableai_ev remains zero and the zero will be dereferencedin the sctp_ulpevent_free() function.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-53905 Severity: Moderate CVSS3 score: 4.1

Description: Vim is an open source, command line text editor. Prior to version 9.1.1552, a path traversal issue in Vim's tar.vim plugin can allow overwriting of arbitrary files when opening specially crafted tar archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1552 contains a patch for the vulnerability.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
vim > 0-0 (version in image is 9.1.1406-160000.3.2).

CVE-2025-53906 Severity: Moderate CVSS3 score: 4.1

Description: Vim is an open source, command line text editor. Prior to version 9.1.1551, a path traversal issue in Vim's zip.vim plugin can allow overwriting of arbitrary files when opening specially crafted zip archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1551 contains a patch for the vulnerability.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
vim > 0-0 (version in image is 9.1.1406-160000.3.2).

CVE-2025-68742 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix invalid prog->stats access when update_effective_progs failsSyzkaller triggers an invalid memory access issue following faultinjection in update_effective_progs. The issue can be described asfollows:__cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog---softirq start---__do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp)---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype])The reason is that fault injection caused update_effective_progs to failand then changed the original prog into dummy_bpf_prog.prog inpurge_effective_progs. Then a softirq came, and accessing the members ofdummy_bpf_prog.prog in the softirq triggers invalid mem access.To fix it, skip updating stats when stats is NULL.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-13837 Severity: Moderate CVSS3 score: 4.0

Description: When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpython3_13-1_0 < 3.13.11-160000.1.1 (version in image is 3.13.5-160000.2.2).

CVE-2025-38448 Severity: Moderate CVSS3 score: 4.0

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: u_serial: Fix race condition in TTY wakeupA race condition occurs when gs_start_io() calls either gs_start_rx() orgs_start_tx(), as those functions briefly drop the port_lock forusb_ep_queue(). This allows gs_close() and gserial_disconnect() to clearport.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

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-5244 Severity: Moderate CVSS3 score: 4.0

Description: A vulnerability was found in GNU Binutils up to 2.44. It has been rated as critical. Affected by this issue is the function elf_gc_sweep of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. Upgrading to version 2.45 is able to address this issue. It is recommended to upgrade the affected component.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-5245 Severity: Moderate CVSS3 score: 4.0

Description: A vulnerability classified as critical has been found in GNU Binutils up to 2.44. This affects the function debug_type_samep of the file /binutils/debug.c of the component objdump. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2026-0988 Severity: Low CVSS3 score: 3.7

Description: A flaw was found in glib. Missing validation of offset and count parameters in the g_buffered_input_stream_peek() function can lead to an integer overflow during length calculation. When specially crafted values are provided, this overflow results in an incorrect size being passed to memcpy(), triggering a buffer overflow. This can cause application crashes, leading to a Denial of Service (DoS).

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
glib2-tools < 2.84.4-160000.2.1 (version in image is 2.84.3-160000.2.2).

CVE-2024-45310 Severity: Low CVSS3 score: 3.6

Description: runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actualuser on the host (such as with rootless containers that don't use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.

Packages affected:

podman > 0-0 (version in image is 5.4.2-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-1147 Severity: Low CVSS3 score: 3.6

Description: A vulnerability has been found in GNU Binutils 2.43 and classified as problematic. Affected by this vulnerability is the function __sanitizer::internal_strlen of the file binutils/nm.c of the component nm. The manipulation of the argument const leads to buffer overflow. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-71080 Severity: Low CVSS3 score: 3.6

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix a BUG in rt6_get_pcpu_route() under PREEMPT_RTOn PREEMPT_RT kernels, after rt6_get_pcpu_route() returns NULL, thecurrent task can be preempted. Another task running on the same CPUmay then execute rt6_make_pcpu_route() and successfully install apcpu_rt entry. When the first task resumes execution, its cmpxchg()in rt6_make_pcpu_route() will fail because rt6i_pcpu is no longerNULL, triggering the BUG_ON(prev). It's easy to reproduce it by addingmdelay() after rt6_get_pcpu_route().Using preempt_disable/enable is not appropriate here becauseip6_rt_pcpu_alloc() may sleep.Fix this by handling the cmpxchg() failure gracefully on PREEMPT_RT:free our allocation and return the existing pcpu_rt installed byanother task. The BUG_ON is replaced by WARN_ON_ONCE for non-PREEMPT_RTkernels where such races should not occur.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-1372 Severity: Moderate CVSS3 score: 3.3

Description: A vulnerability was found in GNU elfutils 0.192. It has been declared as critical. Affected by this vulnerability is the function dump_data_section/print_string_section of the file readelf.c of the component eu-readelf. The manipulation of the argument z/x leads to buffer overflow. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 73db9d2021cab9e23fd734b0a76a612d52a6f1db. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
elfutils > 0-0 (version in image is 0.192-160000.2.2).

CVE-2025-24031 Severity: Moderate CVSS3 score: 3.3

Description: PAM-PKCS#11 is a Linux-PAM login module that allows a X.509 certificate based user login. In versions 0.6.12 and prior, the pam_pkcs11 module segfaults when a user presses ctrl-c/ctrl-d when they are asked for a PIN. When a user enters no PIN at all, `pam_get_pwd` will never initialize the password buffer pointer and as such `cleanse` will try to dereference an uninitialized pointer. On my system this pointer happens to have the value 3 most of the time when running sudo and as such it will segfault. The most likely impact to a system affected by this issue is an availability impact due to a daemon that uses PAM crashing. As of time of publication, a patch for the issue is unavailable.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
pam_pkcs11 > 0-0 (version in image is 0.6.13-160000.2.2).

CVE-2025-3198 Severity: Moderate CVSS3 score: 3.3

Description: A vulnerability has been found in GNU Binutils 2.43/2.44 and classified as problematic. Affected by this vulnerability is the function display_info of the file binutils/bucomm.c of the component objdump. The manipulation leads to memory leak. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The patch is named ba6ad3a18cb26b79e0e3b84c39f707535bbc344d. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-38099 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/brokenA SCO connection without the proper voice_setting can causethe controller to lock up.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38216 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Restore context entry setup order for aliased devicesCommit 2031c469f816 ("iommu/vt-d: Add support for static identity domain")changed the context entry setup during domain attachment from aset-and-check policy to a clear-and-reset approach. This inadvertentlyintroduced a regression affecting PCI aliased devices behind PCIe-to-PCIbridges.Specifically, keyboard and touchpad stopped working on several AppleMacbooks with below messages: kernel: platform pxa2xx-spi.3: Adding to iommu group 20 kernel: input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:1e.3/pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/input/input0 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00Fix this by restoring the previous context setup order.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38270 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: drv: netdevsim: don't napi_complete() from netpollnetdevsim supports netpoll. Make sure we don't call napi_complete()from it, since it may not be scheduled. Breno reports hitting awarning in napi_complete_done():WARNING: CPU: 14 PID: 104 at net/core/dev.c:6592 napi_complete_done+0x2cc/0x560 __napi_poll+0x2d8/0x3a0 handle_softirqs+0x1fe/0x710This is presumably after netpoll stole the SCHED bit prematurely.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38273 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: tipc: fix refcount warning in tipc_aead_encryptsyzbot reported a refcount warning [1] caused by calling get_net() ona network namespace that is being destroyed (refcount=0). This happenswhen a TIPC discovery timer fires during network namespace cleanup.The recently added get_net() call in commit e279024617134 ("net/tipc:fix slab-use-after-free Read in tipc_aead_encrypt_done") attempts tohold a reference to the network namespace. However, if the namespaceis already being destroyed, its refcount might be zero, leading to theuse-after-free warning.Replace get_net() with maybe_get_net(), which safely checks if therefcount is non-zero before incrementing it. If the namespace is beingdestroyed, return -ENODEV early, after releasing the bearer reference.[1]: https://lore.kernel.org/all/68342b55.a70a0220.253bc2.0091.GAE@google.com/T/#m12019cf9ae77e1954f666914640efa36d52704a2

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38528 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject %p% format string in bprintf-like helpersstatic const char fmt[] = "%p%"; bpf_trace_printk(fmt, sizeof(fmt));The above BPF program isn't rejected and causes a kernel warning atruntime: Please remove unsupported %\x00 in format string WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0This happens because bpf_bprintf_prepare skips over the second %,detected as punctuation, while processing %p. This patch fixes it bynot skipping over punctuation. %\x00 is then processed in the nextiteration and rejected.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40353 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: mte: Do not warn if the page is already tagged in copy_highpage()The arm64 copy_highpage() assumes that the destination page is newlyallocated and not MTE-tagged (PG_mte_tagged unset) and warnsaccordingly. However, following commit 060913999d7a ("mm: migrate:support poisoned recover from migrate folio"), folio_mc_copy() is calledbefore __folio_migrate_mapping(). If the latter fails (-EAGAIN), thecopy will be done again to the same destination page. Sincecopy_highpage() already set the PG_mte_tagged flag, this second copywill warn.Replace the WARN_ON_ONCE(page already tagged) in the arm64copy_highpage() with a comment.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-6199 Severity: Moderate CVSS3 score: 3.3

Description: A flaw was found in the GIF parser of GdkPixbuf's LZW decoder. When an invalid symbol is encountered during decompression, the decoder sets the reported output size to the full buffer length rather than the actual number of written bytes. This logic error results in uninitialized sections of the buffer being included in the output, potentially leaking arbitrary memory contents in the processed image.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
gdk-pixbuf-query-loaders < 2.42.12-160000.3.1 (version in image is 2.42.12-160000.2.2).

CVE-2025-68317 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/zctx: check chained notif contextsSend zc only links ubuf_info for requests coming from the same context.There are some ambiguous syz reports, so let's check the assumption onnotification completion.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2026-0989 Severity: Moderate CVSS3 score: 3.3

Description: A flaw was identified in the RelaxNG parser of libxml2 related to how external schema inclusions are handled. The parser does not enforce a limit on inclusion depth when resolving nested directives. Specially crafted or overly complex schemas can cause excessive recursion during parsing. This may lead to stack exhaustion and application crashes, creating a denial-of-service risk.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libxml2-2 > 0-0 (version in image is 2.13.8-160000.2.2).

CVE-2026-0992 Severity: Moderate CVSS3 score: 3.3

Description: A flaw was found in the libxml2 library. This uncontrolled resource consumption vulnerability occurs when processing XML catalogs that contain repeated elements pointing to the same downstream catalog. A remote attacker can exploit this by supplying crafted catalogs, causing the parser to redundantly traverse catalog chains. This leads to excessive CPU consumption and degrades application availability, resulting in a denial-of-service condition.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libxml2-2 > 0-0 (version in image is 2.13.8-160000.2.2).

CVE-2026-22185 Severity: Moderate CVSS3 score: 3.3

Description: OpenLDAP Lightning Memory-Mapped Database (LMDB) versions up to and including 0.9.14, prior to commit 8e1fda8, contain a heap buffer underflow in the readline() function of mdb_load. When processing malformed input containing an embedded NUL byte, an unsigned offset calculation can underflow and cause an out-of-bounds read of one byte before the allocated heap buffer. This can cause mdb_load to crash, leading to a limited denial-of-service condition.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libldap-2 > 0-0 (version in image is 2.6.10+10-160000.2.2).

CVE-2018-15853 Severity: Low CVSS3 score: 3.3

Description: Endless recursion exists in xkbcomp/expr.c in xkbcommon and libxkbcommon before 0.8.1, which could be used by local attackers to crash xkbcommon users by supplying a crafted keymap file that triggers boolean negation.

Packages affected:

xkbcomp < 1.4.7-160000.3.1 (version in image is 1.4.7-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2018-15859 Severity: Low CVSS3 score: 3.3

Description: Unchecked NULL pointer usage when parsing invalid atoms in ExprResolveLhs in xkbcomp/expr.c in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file, because lookup failures are mishandled.

Packages affected:

xkbcomp < 1.4.7-160000.3.1 (version in image is 1.4.7-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2018-15861 Severity: Low CVSS3 score: 3.3

Description: Unchecked NULL pointer usage in ExprResolveLhs in xkbcomp/expr.c in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file that triggers an xkb_intern_atom failure.

Packages affected:

xkbcomp < 1.4.7-160000.3.1 (version in image is 1.4.7-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2018-15863 Severity: Low CVSS3 score: 3.3

Description: Unchecked NULL pointer usage in ResolveStateAndPredicate in xkbcomp/compat.c in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file with a no-op modmask expression.

Packages affected:

xkbcomp < 1.4.7-160000.3.1 (version in image is 1.4.7-160000.2.2).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2023-39327 Severity: Low CVSS3 score: 3.3

Description: A flaw was found in OpenJPEG. Maliciously constructed pictures can cause the program to enter a large loop and continuously print warning messages on the terminal.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libopenjp2-7 > 0-0 (version in image is 2.5.3-160000.2.2).

CVE-2023-45918 Severity: Low CVSS3 score: 3.3

Description: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libncurses6 > 0-0 (version in image is 6.5.20250531-160000.2.2).

CVE-2025-0395 Severity: Low CVSS3 score: 3.3

Description: When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
glibc < 2.40-160000.3.1 (version in image is 2.40-160000.2.2).

CVE-2025-11494 Severity: Low CVSS3 score: 3.3

Description: A vulnerability was found in GNU Binutils 2.45. Impacted is the function _bfd_x86_elf_late_size_sections of the file bfd/elfxx-x86.c of the component Linker. The manipulation results in out-of-bounds read. The attack needs to be approached locally. The exploit has been made public and could be used. The patch is identified as b6ac5a8a5b82f0ae6a4642c8d7149b325f4cc60a. A patch should be applied to remediate this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-11495 Severity: Low CVSS3 score: 3.3

Description: A vulnerability was determined in GNU Binutils 2.45. The affected element is the function elf_x86_64_relocate_section of the file elf64-x86-64.c of the component Linker. This manipulation causes heap-based buffer overflow. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. Patch name: 6b21c8b2ecfef5c95142cbc2c32f185cb1c26ab0. To fix this issue, it is recommended to deploy a patch.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-11839 Severity: Low CVSS3 score: 3.3

Description: A security flaw has been discovered in GNU Binutils 2.45. Impacted is the function tg_tag_type of the file prdbg.c. Performing manipulation results in unchecked return value. The attack needs to be approached locally. The exploit has been released to the public and may be exploited.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils > 0-0 (version in image is 2.43-160000.2.2).

CVE-2025-11840 Severity: Low CVSS3 score: 3.3

Description: A weakness has been identified in GNU Binutils 2.45. The affected element is the function vfinfo of the file ldmisc.c. Executing manipulation can lead to out-of-bounds read. The attack can only be executed locally. The exploit has been made available to the public and could be exploited. This patch is called 16357. It is best practice to apply a patch to resolve this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils > 0-0 (version in image is 2.43-160000.2.2).

CVE-2025-12781 Severity: Low CVSS3 score: 3.3

Description: When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always be accepted, regardless of the value of "altchars" parameter, typically used to establish an "alternative base64 alphabet" such as the URL safe alphabet. This behavior matches what is recommended in earlier base64 RFCs, but newer RFCs now recommend either dropping characters outside the specified base64 alphabet or raising an error. The old behavior has the possibility of causing data integrity issues.This behavior can only be insecure if your application uses an alternate base64 alphabet (without "+/"). If your application does not use the "altchars" parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet.The attached patches DOES NOT make the base64-decode behavior raise an error, as this would be a change in behavior and break existing programs. Instead, the patch deprecates the behavior which will be replaced with the newly recommended behavior in a future version of Python. Users are recommended to mitigate by verifying user-controlled inputs match the base64 alphabet they are expecting or verify that their application would not be affected if the b64decode() functions accepted "+" or "/" outside of altchars.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
python313 > 0-0 (version in image is 3.13.5-160000.2.2).

CVE-2025-28162 Severity: Low CVSS3 score: 3.3

Description: Buffer Overflow vulnerability in libpng 1.6.43-1.6.46 allows a local attacker to cause a denial of service via the pngimage with AddressSanitizer (ASan), the program leaks memory in various locations, eventually leading to high memory usage and causing the program to become unresponsive

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpng16-16 > 0-0 (version in image is 1.6.44-160000.2.2).

CVE-2025-28164 Severity: Low CVSS3 score: 3.3

Description: Buffer Overflow vulnerability in libpng 1.6.43-1.6.46 allows a local attacker to cause a denial of service via png_create_read_struct() function.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpng16-16 > 0-0 (version in image is 1.6.44-160000.2.2).

CVE-2025-38169 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:arm64/fpsimd: Avoid clobbering kernel FPSIMD state with SMSTOPOn system with SME, a thread's kernel FPSIMD state may be erroneouslyclobbered during a context switch immediately after that state isrestored. Systems without SME are unaffected.If the CPU happens to be in streaming SVE mode before a context switchto a thread with kernel FPSIMD state, fpsimd_thread_switch() willrestore the kernel FPSIMD state using fpsimd_load_kernel_state() whilethe CPU is still in streaming SVE mode. When fpsimd_thread_switch()subsequently calls fpsimd_flush_cpu_state(), this will execute anSMSTOP, causing an exit from streaming SVE mode. The exit fromstreaming SVE mode will cause the hardware to reset a number ofFPSIMD/SVE/SME registers, clobbering the FPSIMD state.Fix this by calling fpsimd_flush_cpu_state() before restoring the kernelFPSIMD state.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38228 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:media: imagination: fix a potential memory leak in e5010_probe()Add video_device_release() to release the memory allocated byvideo_device_alloc() if something goes wrong.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38258 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs-schemes: free old damon_sysfs_scheme_filter->memcg_path on writememcg_path_store() assigns a newly allocated memory buffer tofilter->memcg_path, without deallocating the previously allocated andassigned memory buffer. As a result, users can leak kernel memory bycontinuously writing a data to memcg_path DAMOS sysfs file. Fix the leakby deallocating the previously set memory buffer.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38384 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: spinand: fix memory leak of ECC engine confMemory allocated for the ECC engine conf is not released during spinandcleanup. 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/0x160Fix the leak by calling nanddev_ecc_engine_cleanup() insidespinand_cleanup().

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38385 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnectRemove redundant netif_napi_del() call from disconnect path.A WARN may be triggered in __netif_napi_del_locked() during USB devicedisconnect: WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350This happens because netif_napi_del() is called in the disconnect path whileNAPI is still enabled. However, it is not necessary to call netif_napi_del()explicitly, since unregister_netdev() will handle NAPI teardown automaticallyand 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): [] _raw_spin_unlock_irqrestore+0x84/0x98 hardirqs last disabled at (211604): [] el1_dbg+0x24/0x80 softirqs last enabled at (211296): [] handle_softirqs+0x820/0xbc8 softirqs last disabled at (210993): [] __do_softirq+0x18/0x20 ---[ end trace 0000000000000000 ]--- lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38405 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet: fix memory leak of bio integrityIf nvmet receives commands with metadata there is a continuous memoryleak of kmalloc-128 slab or more precisely bio->bi_integrity.Since commit bf4c89fc8797 ("block: don't call bio_uninit from bio_endio")each user of bio_init has to use bio_uninit as well. Otherwise the biointegrity is not getting free. Nvmet uses bio_init for inline bios.Uninit the inline bio to complete deallocation of integrity in bio.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38409 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: Fix another leak in the submit error pathput_unused_fd() doesn't free the installed file, if we've already donefd_install(). So we need to also free the sync_file.Patchwork: https://patchwork.freedesktop.org/patch/653583/

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38417 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix eswitch code memory leak in reset scenarioAdd simple eswitch mode checker in attaching VF procedure and allocaterequired port representor memory structures only in switchdev mode.The reset flows triggers VF (if present) detach/attach procedure.It might involve VF port representor(s) re-creation if the device isconfigured is switchdev mode (not legacy one).The memory was blindly allocated in current implementation,regardless of the mode and not freed if in legacy mode.Kmemeleak trace:unreferenced object (percpu) 0x7e3bce5b888458 (size 40): comm "bash", pid 1784, jiffies 4295743894 hex dump (first 32 bytes on cpu 45): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): pcpu_alloc_noprof+0x4c4/0x7c0 ice_repr_create+0x66/0x130 [ice] ice_repr_create_vf+0x22/0x70 [ice] ice_eswitch_attach_vf+0x1b/0xa0 [ice] ice_reset_all_vfs+0x1dd/0x2f0 [ice] ice_pci_err_resume+0x3b/0xb0 [ice] pci_reset_function+0x8f/0x120 reset_store+0x56/0xa0 kernfs_fop_write_iter+0x120/0x1b0 vfs_write+0x31c/0x430 ksys_write+0x61/0xd0 do_syscall_64+0x5b/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eTesting hints (ethX is PF netdev):- create at least one VF echo 1 > /sys/class/net/ethX/device/sriov_numvfs- trigger the reset echo 1 > /sys/class/net/ethX/device/reset

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38439 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Set DMA unmap len correctly for XDP_REDIRECTWhen transmitting an XDP_REDIRECT packet, call dma_unmap_len_set()with the proper length instead of 0. This bug triggers this warningon a system with IOMMU enabled:WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170RIP: 0010:__iommu_dma_unmap+0x159/0x170Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45b8 4c 89 45 c0 e9 77 ff ff ff <0f> 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00RSP: 0018:ff22d31181150c88 EFLAGS: 00010206RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0PKRU: 55555554Call Trace:? show_regs+0x6d/0x80? __warn+0x89/0x160? __iommu_dma_unmap+0x159/0x170? report_bug+0x17e/0x1b0? handle_bug+0x46/0x90? exc_invalid_op+0x18/0x80? asm_exc_invalid_op+0x1b/0x20? __iommu_dma_unmap+0x159/0x170? __iommu_dma_unmap+0xb3/0x170iommu_dma_unmap_page+0x4f/0x100dma_unmap_page_attrs+0x52/0x220? srso_alias_return_thunk+0x5/0xfbef5? xdp_return_frame+0x2e/0xd0bnxt_tx_int_xdp+0xdf/0x440 [bnxt_en]__bnxt_poll_work_done+0x81/0x1e0 [bnxt_en]bnxt_poll+0xd3/0x1e0 [bnxt_en]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38481 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too largeThe handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer tohold 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 toolarge.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. Setthis to the same value as `MAX_SAMPLES` (65536), which is the maximumallowed sum of the values of the member `n` in the array of `structcomedi_insn`, and sensible comedi instructions will have an `n` of atleast 1.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38506 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Allow CPU to reschedule while setting per-page memory attributesWhen running an SEV-SNP guest with a sufficiently large amount of memory (1TB+),the host can experience CPU soft lockups when running an operation inkvm_vm_set_mem_attributes() to set memory attributes on the wholerange of guest memory.watchdog: BUG: soft lockup - CPU#8 stuck for 26s! [qemu-kvm:6372]CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: loaded Not tainted 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntary)Hardware name: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 11/13/2024RIP: 0010:xas_create+0x78/0x1f0Code: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 <74> 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87RSP: 0018:ffffad890a34b940 EFLAGS: 00000286RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 0000000000000000RDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868R13: ffffad890a356860 R14: 0000000000000000 R15: ffffad890a356868FS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0PKRU: 55555554Call Trace: xas_store+0x58/0x630 __xa_store+0xa5/0x130 xa_store+0x2c/0x50 kvm_vm_set_mem_attributes+0x343/0x710 [kvm] kvm_vm_ioctl+0x796/0xab0 [kvm] __x64_sys_ioctl+0xa3/0xd0 do_syscall_64+0x8c/0x7a0 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7f5578d031bbCode: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48RSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bbRDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 000000000000000bRBP: 0000010000000000 R08: 0000010000000000 R09: 0000017680000000R10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120R13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0While looping through the range of memory setting the attributes,call cond_resched() to give the scheduler a chance to run a higherpriority task on the runqueue if necessary and avoid staying inkernel mode long enough to trigger the lockup.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38549 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix memory leak of efivarfs_fs_info in fs_context error pathsWhen processing mount options, efivarfs allocates efivarfs_fs_info (sfi)early in fs_context initialization. However, sfi is associated with thesuperblock and typically freed when the superblock is destroyed. If thefs_context is released (final put) before fill_super is called-such ason error paths or during reconfiguration-the sfi structure would leak,as ownership never transfers to the superblock.Implement the .free callback in efivarfs_context_ops to ensure anyallocated sfi is properly freed if the fs_context is torn down beforefill_super, preventing this memory leak.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38565 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Exit early on perf_mmap() failWhen perf_mmap() fails to allocate a buffer, it still invokes theevent_mapped() callback of the related event. On X86 this might increasethe perf_rdpmc_allowed reference counter. But nothing undoes this asperf_mmap_close() is never called in this case, which causes anotherreference count leak.Return early on failure to prevent that.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38623 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pnv_php: Fix surprise plug detection and recoveryThe existing PowerNV hotplug code did not handle surprise plug eventscorrectly, leading to a complete failure of the hotplug system after deviceremoval and a required reboot to detect new devices.This comes down to two issues: 1) When a device is surprise removed, often the bridge upstream port will cause a PE freeze on the PHB. If this freeze is not cleared, the MSI interrupts from the bridge hotplug notification logic will not be received by the kernel, stalling all plug events on all slots associated with the PE. 2) When a device is removed from a slot, regardless of surprise or programmatic removal, the associated PHB/PE ls left frozen. If this freeze is not cleared via a fundamental reset, skiboot is unable to clear the freeze and cannot retrain / rescan the slot. This also requires a reboot to clear the freeze and redetect the device in the slot.Issue the appropriate unfreeze and rescan commands on hotplug events,and don't oops on hotplug if pci_bus_to_OF_node() returns NULL.[bhelgaas: tidy comments]

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39957 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: increase scan_ies_len for S1GCurrently the S1G capability element is not taken into accountfor the scan_ies_len, which leads to a buffer length validationfailure in ieee80211_prep_hw_scan() and subsequent WARN in__ieee80211_start_scan(). This prevents hw scanning from functioning.To fix ensure we accommodate for the S1G capability length.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39968 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: add max boundary check for VF filtersThere is no check for max filters that VF can request. Add it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40016 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_IDPer UVC 1.1+ specification 3.7.2, units and terminals must have a non-zerounique ID.```Each Unit and Terminal within the video function is assigned a uniqueidentification number, the Unit ID (UID) or Terminal ID (TID), contained inthe bUnitID or bTerminalID field of the descriptor. The value 0x00 isreserved for undefined ID,```If we add a new entity with id 0 or a duplicated ID, it will be markedas UVC_INVALID_ENTITY_ID.In a previous attempt commit 3dd075fe8ebb ("media: uvcvideo: Requireentities to have a non-zero unique ID"), we ignored all the invalid units,this broke a lot of non-compatible cameras. Hopefully we are more luckythis time.This also prevents some syzkaller reproducers from triggering warnings dueto a chain of entities referring to themselves. In one particular case, anOutput Unit is connected to an Input Unit, both with the same ID of 1. Butwhen looking up for the source ID of the Output Unit, that same entity isfound instead of the input entity, which leads to such warnings.In another case, a backward chain was considered finished as the source IDwas 0. Later on, that entity was found, but its pads were not valid.Here is a sample stack trace for one of those cases.[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd[ 20.830206] usb 1-1: Using ep0 maxpacket: 8[ 20.833501] usb 1-1: config 0 descriptor??[ 21.038518] usb 1-1: string descriptor 0 read error: -71[ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201)[ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized![ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized![ 21.042218] ------------[ cut here ]------------[ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0[ 21.043195] Modules linked in:[ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444[ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014[ 21.044639] Workqueue: usb_hub_wq hub_event[ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0[ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00[ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246[ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1[ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290[ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000[ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003[ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000[ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000[ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0[ 21.051136] PKRU: 55555554[ 21.051331] Call Trace:[ 21.051480] [ 21.051611] ? __warn+0xc4/0x210[ 21.051861] ? media_create_pad_link+0x2c4/0x2e0[ 21.052252] ? report_bug+0x11b/0x1a0[ 21.052540] ? trace_hardirqs_on+0x31/0x40[ 21.052901] ? handle_bug+0x3d/0x70[ 21.053197] ? exc_invalid_op+0x1a/0x50[ 21.053511] ? asm_exc_invalid_op+0x1a/0x20[ 21.053924] ? media_create_pad_link+0x91/0x2e0[ 21.054364] ? media_create_pad_link+0x2c4/0x2e0[ 21.054834] ? media_create_pad_link+0x91/0x2e0[ 21.055131] ? _raw_spin_unlock+0x1e/0x40[ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210[ 21.055837] uvc_mc_register_entities+0x358/0x400[ 21.056144] uvc_register_chains+0x1---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40101 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix memory leaks when rejecting a non SINGLE data profile without an RSTAt the end of btrfs_load_block_group_zone_info() the first thing we dois to ensure that if the mapping type is not a SINGLE one and there isno RAID stripe tree, then we return early with an error.Doing that, though, prevents the code from running the last calls fromthis function which are about freeing memory allocated during itsrun. Hence, in this case, instead of returning early, we set the retvalue and fall through the rest of the cleanup code.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40105 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:vfs: Don't leak disconnected dentries on umountWhen user calls open_by_handle_at() on some inode that is not cached, wewill create disconnected dentry for it. If such dentry is a directory,exportfs_decode_fh_raw() will then try to connect this dentry to thedentry tree through reconnect_path(). It may happen for various reasons(such as corrupted fs or race with rename) that the call tolookup_one_unlocked() in reconnect_one() will fail to find the dentry weare trying to reconnect and instead create a new dentry under theparent. Now this dentry will not be marked as disconnected although theparent still may well be disconnected (at least in case thisinconsistency happened because the fs is corrupted and .. doesn't pointto the real parent directory). This creates inconsistency indisconnected flags but AFAICS it was mostly harmless. At least untilcommit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon")which removed adding of most disconnected dentries to sb->s_anon list.Thus after this commit cleanup of disconnected dentries implicitelyrelies on the fact that dput() will immediately reclaim such dentries.However when some leaf dentry isn't marked as disconnected, as in thescenario described above, the reclaim doesn't happen and the dentriesare "leaked". Memory reclaim can eventually reclaim them but otherwisethey stay in memory and if umount comes first, we hit infamous "Busyinodes after unmount" bug. Make sure all dentries created under adisconnected parent are marked as disconnected as well.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40140 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicastsyzbot reported WARNING in rtl8150_start_xmit/usb_submit_urb.This is the sequence of events that leads to the warning:rtl8150_start_xmit() { netif_stop_queue(); usb_submit_urb(dev->tx_urb);}rtl8150_set_multicast() { netif_stop_queue(); netif_wake_queue(); <-- wakes up TX queue before URB is done}rtl8150_start_xmit() { netif_stop_queue(); usb_submit_urb(dev->tx_urb); <-- double submission}rtl8150_set_multicast being the ndo_set_rx_mode callback should not becalling netif_stop_queue and notif_start_queue as these handleTX queue synchronization.The net core function dev_set_rx_mode handles the synchronizationfor rtl8150_set_multicast making it safe to remove these locks.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40153 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:mm: hugetlb: avoid soft lockup when mprotect to large memory areaWhen calling mprotect() to a large hugetlb memory area in our customer'sworkload (~300GB hugetlb memory), soft lockup was observed:watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : mte_clear_page_tags+0x14/0x24lr : mte_sync_tags+0x1c0/0x240sp : ffff80003150bb80x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2cx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000Call trace: mte_clear_page_tags+0x14/0x24 set_huge_pte_at+0x25c/0x280 hugetlb_change_protection+0x220/0x430 change_protection+0x5c/0x8c mprotect_fixup+0x10c/0x294 do_mprotect_pkey.constprop.0+0x2e0/0x3d4 __arm64_sys_mprotect+0x24/0x44 invoke_syscall+0x50/0x160 el0_svc_common+0x48/0x144 do_el0_svc+0x30/0xe0 el0_svc+0x30/0xf0 el0t_64_sync_handler+0xc4/0x148 el0t_64_sync+0x1a4/0x1a8Soft lockup is not triggered with THP or base page because there iscond_resched() called for each PMD size.Although the soft lockup was triggered by MTE, it should be not MTEspecific. The other processing which takes long time in the loop maytrigger soft lockup too.So add cond_resched() for hugetlb to avoid soft lockup.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40160 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:xen/events: Return -EEXIST for bound VIRQsChange find_virq() to return -EEXIST when a VIRQ is bound to adifferent CPU than the one passed in. With that, remove the BUG_ON()from bind_virq_to_irq() to propogate the error upwards.Some VIRQs are per-cpu, but others are per-domain or global. Those mustbe bound to CPU0 and can then migrate elsewhere. The lookup forper-domain and global will probably fail when migrated off CPU 0,especially when the current CPU is tracked. This now returns -EEXISTinstead of BUG_ON().A second call to bind a per-domain or global VIRQ is not expected, butmake it non-fatal to avoid trying to look up the irq, since we don'tknow which per_cpu(virq_to_irq) it will be in.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40196 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:fs: quota: create dedicated workqueue for quota_release_workThere is a kernel panic due to WARN_ONCE when panic_on_warn is set.This issue occurs when writeback is triggered due to sync call for anopened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balanceis needed at sync path, flush for quota_release_work is triggered.By default quota_release_work is queued to "events_unbound" queue whichdoes not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback"workqueue tries to flush quota_release_work causing kernel panic due toMEM_RECLAIM flag mismatch errors.This patch creates dedicated workqueue with WQ_MEM_RECLAIM flagfor work quota_release_work.------------[ cut here ]------------WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20Kernel panic - not syncing: kernel: panic_on_warn set ...

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40311 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:accel/habanalabs: support mapping cb with vmalloc-backed coherent memoryWhen IOMMU is enabled, dma_alloc_coherent() with GFP_USER may returnaddresses from the vmalloc range. If such an address is mapped withoutVM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to theVM_PFNMAP restriction.Fix this by checking for vmalloc addresses and setting VM_MIXEDMAPin the VMA before mapping. This ensures safe mapping and avoids kernelcrashes. The memory is still driver-allocated and cannot be accesseddirectly by userspace.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-50422 Severity: Low CVSS3 score: 3.3

Description: Cairo through 1.18.4, as used in Poppler through 25.08.0, has an "unscaled->face == NULL" assertion failure for _cairo_ft_unscaled_font_fini in cairo-ft-font.c.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libcairo-gobject2 > 0-0 (version in image is 1.18.4-160000.2.2).

CVE-2025-68751 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:s390/fpu: Fix false-positive kmsan report in fpu_vstl()A false-positive kmsan report is detected when running ping command.An inline assembly instruction 'vstl' can write varied amount of bytesdepending on value of 'index' argument. If 'index' > 0, 'vstl' writesat least 2 bytes.clang generates kmsan write helper call depending on inline assemblyconstraints. Constraints are evaluated compile-time, but value of'index' argument is known only at runtime.clang currently generates call to __msan_instrument_asm_store with 1 byteas size. Manually call kmsan function to indicate correct amount of byteswritten and fix false-positive report.This change fixes following kmsan reports:[ 36.563119] =====================================================[ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70[ 36.563852] virtqueue_add+0x35c6/0x7c70[ 36.564016] virtqueue_add_outbuf+0xa0/0xb0[ 36.564266] start_xmit+0x288c/0x4a20[ 36.564460] dev_hard_start_xmit+0x302/0x900[ 36.564649] sch_direct_xmit+0x340/0xea0[ 36.564894] __dev_queue_xmit+0x2e94/0x59b0[ 36.565058] neigh_resolve_output+0x936/0xb40[ 36.565278] __neigh_update+0x2f66/0x3a60[ 36.565499] neigh_update+0x52/0x60[ 36.565683] arp_process+0x1588/0x2de0[ 36.565916] NF_HOOK+0x1da/0x240[ 36.566087] arp_rcv+0x3e4/0x6e0[ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0[ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0[ 36.566710] napi_complete_done+0x376/0x740[ 36.566918] virtnet_poll+0x1bae/0x2910[ 36.567130] __napi_poll+0xf4/0x830[ 36.567294] net_rx_action+0x97c/0x1ed0[ 36.567556] handle_softirqs+0x306/0xe10[ 36.567731] irq_exit_rcu+0x14c/0x2e0[ 36.567910] do_io_irq+0xd4/0x120[ 36.568139] io_int_handler+0xc2/0xe8[ 36.568299] arch_cpu_idle+0xb0/0xc0[ 36.568540] arch_cpu_idle+0x76/0xc0[ 36.568726] default_idle_call+0x40/0x70[ 36.568953] do_idle+0x1d6/0x390[ 36.569486] cpu_startup_entry+0x9a/0xb0[ 36.569745] rest_init+0x1ea/0x290[ 36.570029] start_kernel+0x95e/0xb90[ 36.570348] startup_continue+0x2e/0x40[ 36.570703][ 36.570798] Uninit was created at:[ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0[ 36.571261] kmalloc_reserve+0x12a/0x470[ 36.571553] __alloc_skb+0x310/0x860[ 36.571844] __ip_append_data+0x483e/0x6a30[ 36.572170] ip_append_data+0x11c/0x1e0[ 36.572477] raw_sendmsg+0x1c8c/0x2180[ 36.572818] inet_sendmsg+0xe6/0x190[ 36.573142] __sys_sendto+0x55e/0x8e0[ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0[ 36.573571] __do_syscall+0x12e/0x240[ 36.573823] system_call+0x6e/0x90[ 36.573976][ 36.574017] Byte 35 of 98 is uninitialized[ 36.574082] Memory access of size 98 starts at 0000000007aa0012[ 36.574218][ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE[ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST[ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux)[ 36.574755] =====================================================[ 63.532541] =====================================================[ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70[ 63.533989] virtqueue_add+0x35c6/0x7c70[ 63.534940] virtqueue_add_outbuf+0xa0/0xb0[ 63.535861] start_xmit+0x288c/0x4a20[ 63.536708] dev_hard_start_xmit+0x302/0x900[ 63.537020] sch_direct_xmit+0x340/0xea0[ 63.537997] __dev_queue_xmit+0x2e94/0x59b0[ 63.538819] neigh_resolve_output+0x936/0xb40[ 63.539793] ip_finish_output2+0x1ee2/0x2200[ 63.540784] __ip_finish_output+0x272/0x7a0[ 63.541765] ip_finish_output+0x4e/0x5e0[ 63.542791] ip_output+0x166/0x410[ 63.543771] ip_push_pending_frames+0x1a2/0x470[ 63.544753] raw_sendmsg+0x1f06/0x2180[ 63.545033] inet_sendmsg+0xe6/0x190[ 63.546006] __sys_sendto+0x55e/0x8e0---truncated---

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71094 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix: validate PHY address before useThe ASIX driver reads the PHY address from the USB device viaasix_read_phy_addr(). A malicious or faulty device can return aninvalid address (>= PHY_MAX_ADDR), which causes a warning inmdiobus_get_phy(): addr 207 out of range WARNING: drivers/net/phy/mdio_bus.c:76Validate the PHY address in asix_read_phy_addr() and remove thenow-redundant check in ax88172a.c.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71125 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Do not register unsupported perf eventsSynthetic events currently do not have a function to register perf events.This leads to calling the tracepoint register functions with a NULLfunction pointer which triggers: ------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepoint_add_func+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: tracepoint_probe_register+0x5d/0x90 synth_event_reg+0x3c/0x60 perf_trace_event_init+0x204/0x340 perf_trace_init+0x85/0xd0 perf_tp_event_init+0x2e/0x50 perf_try_init_event+0x6f/0x230 ? perf_event_alloc+0x4bb/0xdc0 perf_event_alloc+0x65a/0xdc0 __se_sys_perf_event_open+0x290/0x9f0 do_syscall_64+0x93/0x7b0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? trace_hardirqs_off+0x53/0xc0 entry_SYSCALL_64_after_hwframe+0x76/0x7eInstead, have the code return -ENODEV, which doesn't warn and has perferror out with: # perf record -e synthetic:futex_waitError:The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait)."dmesg | grep -i perf" may provide additional information.Ideally perf should support synthetic events, but for now just fix thewarning. The support can come later.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-71160 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: avoid chain re-validation if possibleHamza Mahfooz reports cpu soft lock-ups innft_chain_validate(): watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547][..] RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables][..] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_table_validate+0x6b/0xb0 [nf_tables] nf_tables_validate+0x8b/0xa0 [nf_tables] nf_tables_commit+0x1df/0x1eb0 [nf_tables][..]Currently nf_tables will traverse the entire table (chain graph), startingfrom the entry points (base chains), exploring all possible paths(chain jumps). But there are cases where we could avoid revalidation.Consider:1 input -> j2 -> j32 input -> j2 -> j33 input -> j1 -> j2 -> j3Then the second rule does not need to revalidate j2, and, by extension j3,because this was already checked during validation of the first rule.We need to validate it only for rule 3.This is needed because chain loop detection also ensures we do not exceedthe jump stack: Just because we know that j2 is cycle free, its last jumpmight now exceed the allowed stack size. We also need to update allreachable chains with the new largest observed call depth.Care has to be taken to revalidate even if the chain depth won't be anissue: chain validation also ensures that expressions are not called frominvalid base chains. For example, the masquerade expression can only becalled from NAT postrouting base chains.Therefore we also need to keep record of the base chain context (type,hooknum) and revalidate if the chain becomes reachable from a differenthook location.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-8224 Severity: Low CVSS3 score: 3.3

Description: A vulnerability has been found in GNU Binutils 2.44 and classified as problematic. This vulnerability affects the function bfd_elf_get_str_section of the file bfd/elf.c of the component BFD Library. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The name of the patch is db856d41004301b3a56438efd957ef5cabb91530. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-8225 Severity: Low CVSS3 score: 3.3

Description: A vulnerability was found in GNU Binutils 2.44 and classified as problematic. This issue affects the function process_debug_info of the file binutils/dwarf.c of the component DWARF Section Handler. The manipulation leads to memory leak. Attacking locally is a requirement. The identifier of the patch is e51fdff7d2e538c0e5accdd65649ac68e6e0ddd4. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-8291 Severity: Low CVSS3 score: 3.3

Description: The 'zipfile' module would not check the validity of the ZIP64 End ofCentral Directory (EOCD) Locator record offset value would not be used tolocate the ZIP64 EOCD record, instead the ZIP64 EOCD record would beassumed to be the previous record in the ZIP archive. This could be abusedto create ZIP archives that are handled differently by the 'zipfile' modulecompared to other ZIP implementations.Remediation maintains this behavior, but checks that the offset specifiedin the ZIP64 EOCD Locator record matches the expected value.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpython3_13-1_0 < 3.13.11-160000.1.1 (version in image is 3.13.5-160000.2.2).

CVE-2025-8732 Severity: Low CVSS3 score: 3.3

Description: A vulnerability was found in libxml2 up to 2.14.5. It has been declared as problematic. This vulnerability affects the function xmlParseSGMLCatalog of the component xmlcatalog. The manipulation leads to uncontrolled recursion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that "[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all."

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
envsubst > 0-0 (version in image is 0.22.5-160000.2.2).

CVE-2025-8961 Severity: Low CVSS3 score: 3.3

Description: A weakness has been identified in LibTIFF 4.7.0. This affects the function main of the file tiffcrop.c of the component tiffcrop. Executing manipulation can lead to memory corruption. The attack can only be executed locally. The exploit has been made available to the public and could be exploited.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libtiff6 < 4.7.1-160000.1.1 (version in image is 4.7.0-160000.2.2).

CVE-2025-9165 Severity: Low CVSS3 score: 3.3

Description: A flaw has been found in LibTIFF 4.7.0. This affects the function _TIFFmallocExt/_TIFFCheckRealloc/TIFFHashSetNew/InitCCITTFax3 of the file tools/tiffcmp.c of the component tiffcmp. Executing manipulation can lead to memory leak. The attack is restricted to local execution. This attack is characterized by high complexity. It is indicated that the exploitability is difficult. The exploit has been published and may be used. There is ongoing doubt regarding the real existence of this vulnerability. This patch is called ed141286a37f6e5ddafb5069347ff5d587e7a4e0. It is best practice to apply a patch to resolve this issue. A researcher disputes the security impact of this issue, because "this is a memory leak on a command line tool that is about to exit anyway". In the reply the project maintainer declares this issue as "a simple 'bug' when leaving the command line tool and (...) not a security issue at all".

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libtiff6 < 4.7.1-160000.1.1 (version in image is 4.7.0-160000.2.2).

CVE-2026-1485 Severity: Low CVSS3 score: 3.3

Description: A flaw was found in Glib's content type parsing logic. This buffer underflow vulnerability occurs because the length of a header line is stored in a signed integer, which can lead to integer wraparound for very large inputs. This results in pointer underflow and out-of-bounds memory access. Exploitation requires a local user to install or process a specially crafted treemagic file, which can lead to local denial of service or application instability.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
glib2-tools < 2.84.4-160000.2.1 (version in image is 2.84.3-160000.2.2).

CVE-2026-1757 Severity: Low CVSS3 score: 3.3

Description: A flaw was identified in the interactive shell of the xmllint utility, part of the libxml2 project, where memory allocated for user input is not properly released under certain conditions. When a user submits input consisting only of whitespace, the program skips command execution but fails to free the allocated buffer. Repeating this action causes memory to continuously accumulate. Over time, this can exhaust system memory and terminate the xmllint process, creating a denial-of-service condition on the local system.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libxml2-2 > 0-0 (version in image is 2.13.8-160000.2.2).

CVE-2026-23023 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix memory leak in idpf_vport_rel()Free vport->rx_ptype_lkup in idpf_vport_rel() to avoid leaking memoryduring a reset. Reported by kmemleak:unreferenced object 0xff450acac838a000 (size 4096): comm "kworker/u258:5", pid 7732, jiffies 4296830044 hex dump (first 32 bytes): 00 00 00 00 00 10 00 00 00 10 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 ................ backtrace (crc 3da81902): __kmalloc_cache_noprof+0x469/0x7a0 idpf_send_get_rx_ptype_msg+0x90/0x570 [idpf] idpf_init_task+0x1ec/0x8d0 [idpf] process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x251/0x2b0 ret_from_fork_asm+0x1a/0x30

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23024 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix memory leak of flow steer list on rmmodThe flow steering list maintains entries that are added and removed asethtool creates and deletes flow steering rules. Module removal with activeentries causes memory leak as the list is not properly cleaned up.Prevent this by iterating through the remaining entries in the list andfreeing the associated memory during module removal. Add a spinlock(flow_steer_list_lock) to protect the list access from multiple threads.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23032 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:null_blk: fix kmemleak by releasing references to fault configfs itemsWhen CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blkdriver sets up fault injection support by creating the timeout_inject,requeue_inject, and init_hctx_fault_inject configfs items as childrenof the top-level nullbX configfs group.However, when the nullbX device is removed, the references taken tothese fault-config configfs items are not released. As a result,kmemleak reports a memory leak, for example:unreferenced object 0xc00000021ff25c40 (size 32): comm "mkdir", pid 10665, jiffies 4322121578 hex dump (first 32 bytes): 69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f init_hctx_fault_ 69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject.......... backtrace (crc 1a018c86): __kmalloc_node_track_caller_noprof+0x494/0xbd8 kvasprintf+0x74/0xf4 config_item_set_name+0xf0/0x104 config_group_init_type_name+0x48/0xfc fault_config_init+0x48/0xf0 0xc0080000180559e4 configfs_mkdir+0x304/0x814 vfs_mkdir+0x49c/0x604 do_mkdirat+0x314/0x3d0 sys_mkdir+0xa0/0xd8 system_call_exception+0x1b0/0x4f0 system_call_vectored_common+0x15c/0x2ecFix this by explicitly releasing the references to the fault-configconfigfs items when dropping the reference to the top-level nullbXconfigfs group.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2026-23083 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:fou: Don't allow 0 for FOU_ATTR_IPPROTO.fou_udp_recv() has the same problem mentioned in the previouspatch.If FOU_ATTR_IPPROTO is set to 0, skb is not freed byfou_udp_recv() nor "resubmit"-ted in ip_protocol_deliver_rcu().Let's forbid 0 for FOU_ATTR_IPPROTO.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-15224 Severity: Moderate CVSS3 score: 3.1

Description: When doing SSH-based transfers using either SCP or SFTP, and asked to dopublic key authentication, curl would wrongly still ask and authenticate usinga locally running SSH agent.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
curl < 8.14.1-160000.4.1 (version in image is 8.14.1-160000.2.2).

CVE-2025-38356 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/guc: Explicitly exit CT safe mode on unwindDuring driver probe we might be briefly using CT safe mode, whichis based on a delayed work, but usually we are able to stop thisonce we have IRQ fully operational. However, if we abort the probequite early then during unwind we might try to destroy the workqueuewhile there is still a pending delayed work that attempts to restartitself which triggers a WARN.This was recently observed during unsuccessful VF initialization: [ ] xe 0000:00:02.1: probe with driver xe failed with error -62 [ ] ------------[ cut here ]------------ [ ] workqueue: cannot queue safe_mode_worker_func [xe] on wq xe-g2h-wq [ ] WARNING: CPU: 9 PID: 0 at kernel/workqueue.c:2257 __queue_work+0x287/0x710 [ ] RIP: 0010:__queue_work+0x287/0x710 [ ] Call Trace: [ ] delayed_work_timer_fn+0x19/0x30 [ ] call_timer_fn+0xa1/0x2a0Exit the CT safe mode on unwind to avoid that warning.(cherry picked from commit 2ddbb73ec20b98e70a5200cb85deade22ccea2ec)

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-54798 Severity: Moderate CVSS3 score: 2.5

Description: tmp is a temporary file and directory creator for node.js. In versions 0.2.3 and below, tmp is vulnerable to an arbitrary temporary file / directory write via symbolic link dir parameter. This is fixed in version 0.2.4.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
cockpit > 0-0 (version in image is 340-160000.3.2).

CVE-2025-66863 Severity: Moderate CVSS3 score: 2.5

Description: An issue was discovered in function d_discriminator in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils > 0-0 (version in image is 2.43-160000.2.2).

CVE-2025-66866 Severity: Moderate CVSS3 score: 2.5

Description: An issue was discovered in function d_abi_tags in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils > 0-0 (version in image is 2.43-160000.2.2).

CVE-2025-1150 Severity: Low CVSS3 score: 2.5

Description: A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. This vulnerability affects the function bfd_malloc of the file libbfd.c of the component ld. The manipulation leads to memory leak. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-1352 Severity: Low CVSS3 score: 2.5

Description: A vulnerability has been found in GNU elfutils 0.192 and classified as critical. This vulnerability affects the function __libdw_thread_tail in the library libdw_alloc.c of the component eu-readelf. The manipulation of the argument w leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 2636426a091bd6c6f7f02e49ab20d4cdc6bfc753. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
elfutils > 0-0 (version in image is 0.192-160000.2.2).

CVE-2025-1376 Severity: Low CVSS3 score: 2.5

Description: A vulnerability classified as problematic was found in GNU elfutils 0.192. This vulnerability affects the function elf_strptr in the library /libelf/elf_strptr.c of the component eu-strip. The manipulation leads to denial of service. It is possible to launch the attack on the local host. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is b16f441cca0a4841050e3215a9f120a6d8aea918. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
elfutils > 0-0 (version in image is 0.192-160000.2.2).

CVE-2025-38058 Severity: Low CVSS3 score: 2.5

Description: 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_countafter umount(2) has verified that victim is not busy, but before ithas set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't seethat it's safe to quietly undo mnt_count increment and leaves droppingthe reference to caller, where it'll be a full-blown mntput().Check under mount_lock is needed; leaving the current one done beforetaking that makes no sense - it's nowhere near common enough to botherwith.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38103 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()Update struct hid_descriptor to better reflect the mandatory andoptional parts of the HID Descriptor as per USB HID 1.11 specification.Note: the kernel currently does not parse any optional HID classdescriptors, only the mandatory report descriptor.Update all references to member element desc[0] to rpt_desc.Add test to verify bLength and bNumDescriptors values are valid.Replace the for loop with direct access to the mandatory HID classdescriptor member for the report descriptor. This eliminates thepossibility of getting an out-of-bounds fault.Add a warning message if the HID descriptor contains any unsupportedoptional HID class descriptors.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38267 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Do not trigger WARN_ON() due to a commit_overrunWhen reading a memory mapped buffer the reader page is just swapped outwith the last page written in the write buffer. If the reader page is thesame as the commit buffer (the buffer that is currently being written to)it was assumed that it should never have missed events. If it does, ittriggers a WARN_ON_ONCE().But there just happens to be one scenario where this can legitimatelyhappen. That is on a commit_overrun. A commit overrun is when an interruptpreempts an event being written to the buffer and then the interrupt addsso many new events that it fills and wraps the buffer back to the commit.Any new events would then be dropped and be reported as "missed_events".In this case, the next page to read is the commit buffer and after theswap of the reader page, the reader page will be the commit buffer, butthis time there will be missed events and this triggers the followingwarning: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1127 at kernel/trace/ring_buffer.c:7357 ring_buffer_map_get_reader+0x49a/0x780 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 1127 Comm: trace-cmd Not tainted 6.15.0-rc7-test-00004-g478bc2824b45-dirty #564 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:ring_buffer_map_get_reader+0x49a/0x780 Code: 00 00 00 48 89 fe 48 c1 ee 03 80 3c 2e 00 0f 85 ec 01 00 00 4d 3b a6 a8 00 00 00 0f 85 8a fd ff ff 48 85 c0 0f 84 55 fe ff ff <0f> 0b e9 4e fe ff ff be 08 00 00 00 4c 89 54 24 58 48 89 54 24 50 RSP: 0018:ffff888121787dc0 EFLAGS: 00010002 RAX: 00000000000006a2 RBX: ffff888100062800 RCX: ffffffff8190cb49 RDX: ffff888126934c00 RSI: 1ffff11020200a15 RDI: ffff8881010050a8 RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffed1024d26982 R10: ffff888126934c17 R11: ffff8881010050a8 R12: ffff888126934c00 R13: ffff8881010050b8 R14: ffff888101005000 R15: ffff888126930008 FS: 00007f95c8cd7540(0000) GS:ffff8882b576e000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f95c8de4dc0 CR3: 0000000128452002 CR4: 0000000000172ef0 Call Trace: ? __pfx_ring_buffer_map_get_reader+0x10/0x10 tracing_buffers_ioctl+0x283/0x370 __x64_sys_ioctl+0x134/0x190 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f95c8de48db Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00 RSP: 002b:00007ffe037ba110 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe037bb2b0 RCX: 00007f95c8de48db RDX: 0000000000000000 RSI: 0000000000005220 RDI: 0000000000000006 RBP: 00007ffe037ba180 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe037bb6f8 R14: 00007f95c9065000 R15: 00005575c7492c90 irq event stamp: 5080 hardirqs last enabled at (5079): [] _raw_spin_unlock_irqrestore+0x50/0x70 hardirqs last disabled at (5080): [] _raw_spin_lock_irqsave+0x63/0x70 softirqs last enabled at (4182): [] handle_softirqs+0x552/0x710 softirqs last disabled at (4159): [] __irq_exit_rcu+0x107/0x210 ---[ end trace 0000000000000000 ]---The above was triggered by running on a kernel with both lockdep and KASANas well as kmemleak enabled and executing the following command: # perf record -o perf-test.dat -a -- trace-cmd record --nosplice -e all -p function hackbench 50With perf interjecting a lot of interrupts and trace-cmd enabling allevents as well as function tracing, with lockdep, KASAN and kmemleakenabled, it could cause an interrupt preempting an event being written toadd enough event---truncated---

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38291 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Prevent sending WMI commands to firmware during firmware crashCurrently, we encounter the following kernel call trace when a firmwarecrash occurs. This happens because the host sends WMI commands to thefirmware while it is in recovery, causing the commands to fail andresulting in the kernel call trace.Set the ATH12K_FLAG_CRASH_FLUSH and ATH12K_FLAG_RECOVERY flags when thehost driver receives the firmware crash notification from MHI. Thisprevents sending WMI commands to the firmware during recovery.Call Trace: dump_stack_lvl+0x75/0xc0 register_lock_class+0x6be/0x7a0 ? __lock_acquire+0x644/0x19a0 __lock_acquire+0x95/0x19a0 lock_acquire+0x265/0x310 ? ath12k_ce_send+0xa2/0x210 [ath12k] ? find_held_lock+0x34/0xa0 ? ath12k_ce_send+0x56/0x210 [ath12k] _raw_spin_lock_bh+0x33/0x70 ? ath12k_ce_send+0xa2/0x210 [ath12k] ath12k_ce_send+0xa2/0x210 [ath12k] ath12k_htc_send+0x178/0x390 [ath12k] ath12k_wmi_cmd_send_nowait+0x76/0xa0 [ath12k] ath12k_wmi_cmd_send+0x62/0x190 [ath12k] ath12k_wmi_pdev_bss_chan_info_request+0x62/0xc0 [ath1 ath12k_mac_op_get_survey+0x2be/0x310 [ath12k] ieee80211_dump_survey+0x99/0x240 [mac80211] nl80211_dump_survey+0xe7/0x470 [cfg80211] ? kmalloc_reserve+0x59/0xf0 genl_dumpit+0x24/0x70 netlink_dump+0x177/0x360 __netlink_dump_start+0x206/0x280 genl_family_rcv_msg_dumpit.isra.22+0x8a/0xe0 ? genl_family_rcv_msg_attrs_parse.isra.23+0xe0/0xe0 ? genl_op_lock.part.12+0x10/0x10 ? genl_dumpit+0x70/0x70 genl_rcv_msg+0x1d0/0x290 ? nl80211_del_station+0x330/0x330 [cfg80211] ? genl_get_cmd_both+0x50/0x50 netlink_rcv_skb+0x4f/0x100 genl_rcv+0x1f/0x30 netlink_unicast+0x1b6/0x260 netlink_sendmsg+0x31a/0x450 __sock_sendmsg+0xa8/0xb0 ____sys_sendmsg+0x1e4/0x260 ___sys_sendmsg+0x89/0xe0 ? local_clock_noinstr+0xb/0xc0 ? rcu_is_watching+0xd/0x40 ? kfree+0x1de/0x370 ? __sys_sendmsg+0x7a/0xc0Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39737 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()A soft lockup warning was observed on a relative small system x86-64system with 16 GB of memory when running a debug kernel with kmemleakenabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]The test system was running a workload with hot unplug happening inparallel. Then kemleak decided to disable itself due to its inability toallocate more kmemleak objects. The debug kernel has itsCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.The soft lockup happened in kmemleak_do_cleanup() when the existingkmemleak objects were being removed and deleted one-by-one in a loop via aworkqueue. In this particular case, there are at least 40,000 objectsthat need to be processed and given the slowness of a debug kernel and thefact that a raw_spinlock has to be acquired and released in__delete_object(), it could take a while to properly handle all theseobjects.As kmemleak has been disabled in this case, the object removal anddeletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edgecase that should rarely happen. So the simple solution is to callcond_resched() at periodic interval in the iteration loop to avoid softlockup.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-40359 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel: Fix KASAN global-out-of-bounds warningWhen running "perf mem record" command on CWF, the below KASANglobal-out-of-bounds warning is seen. ================================================================== BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0 Read of size 4 at addr ffffffffb721d000 by task dtlb/9850 Call Trace: kasan_report+0xb8/0xf0 cmt_latency_data+0x176/0x1b0 setup_arch_pebs_sample_data+0xf49/0x2560 intel_pmu_drain_arch_pebs+0x577/0xb00 handle_pmi_common+0x6c4/0xc80The issue is caused by below code in __grt_latency_data(). The codetries to access x86_hybrid_pmu structure which doesn't exist onnon-hybrid platform like CWF. WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big)So add is_hybrid() check before calling this WARN_ON_ONCE to fix theglobal-out-of-bounds access issue.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.9.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40363 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix field-spanning memcpy warning in AH outputFix field-spanning memcpy warnings in ah6_output() andah6_output_done() where extension headers are copied to/from IPv6address fields, triggering fortify-string warnings about writes beyondthe 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439The warnings are false positives as the extension headers areintentionally placed after the IPv6 header in memory. Fix by properlycopying addresses and extension headers separately, and introducehelper functions to avoid code duplication.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-5889 Severity: Low CVSS3 score: 2.5

Description: A vulnerability was found in juliangruber brace-expansion up to 1.1.11/2.0.1/3.0.0/4.0.0. It has been rated as problematic. Affected by this issue is the function expand of the file index.js. The manipulation leads to inefficient regular expression complexity. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.1.12, 2.0.2, 3.0.1 and 4.0.1 is able to address this issue. The name of the patch is a5b98a4f30d7813266b221435e1eaaf25a1b0ac5. It is recommended to upgrade the affected component.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
cockpit > 0-0 (version in image is 340-160000.3.2).

CVE-2025-6075 Severity: Low CVSS3 score: 2.5

Description: If the value passed to os.path.expandvars() is user-controlled a performance degradation is possible when expanding environment variables.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libpython3_13-1_0 < 3.13.11-160000.1.1 (version in image is 3.13.5-160000.2.2).

CVE-2025-66861 Severity: Low CVSS3 score: 2.5

Description: An issue was discovered in function d_unqualified_name in file cp-demangle.c in BinUtils 2.26 allowing attackers to cause a denial of service via crafted PE file.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils > 0-0 (version in image is 2.43-160000.2.2).

CVE-2025-66864 Severity: Low CVSS3 score: 2.5

Description: An issue was discovered in function d_print_comp_inner in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils > 0-0 (version in image is 2.43-160000.2.2).

CVE-2025-66865 Severity: Low CVSS3 score: 2.5

Description: An issue was discovered in function d_print_comp_inner in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils > 0-0 (version in image is 2.43-160000.2.2).

CVE-2025-71084 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cm: Fix leaking the multicast GID table referenceIf the CM ID is destroyed while the CM event for multicast creating isstill queued the cancel_work_sync() will prevent the work from runningwhich also prevents destroying the ah_attr. This leaks a refcount andtriggers a WARN: GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886Destroy the ah_attr after canceling the work, it is safe to call thistwice.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
kernel-default > 0-0 (version in image is 6.12.0-160000.5.1).

CVE-2025-8534 Severity: Low CVSS3 score: 2.5

Description: A vulnerability classified as problematic was found in libtiff 4.6.0. This vulnerability affects the function PS_Lvl2page of the file tools/tiff2ps.c of the component tiff2ps. The manipulation leads to null pointer dereference. It is possible to launch the attack on the local host. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 6ba36f159fd396ad11bf6b7874554197736ecc8b. It is recommended to apply a patch to fix this issue. One of the maintainers explains, that "[t]his error only occurs if DEFER_STRILE_LOAD (defer-strile-load:BOOL=ON) or TIFFOpen( .. "rD") option is used."

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libtiff6 < 4.7.1-160000.1.1 (version in image is 4.7.0-160000.2.2).

CVE-2025-10148 Severity: Moderate CVSS3 score: None

Description: 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 thatpersisted and was used throughout the entire connection.A predictable mask pattern allows for a malicious server to induce trafficbetween the two communicating parties that could be interpreted by an involvedproxy (configured or transparent) as genuine, real, HTTP traffic with contentand thereby poison its cache. That cached poisoned content could then beserved to all users of that proxy.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
curl < 8.14.1-160000.3.1 (version in image is 8.14.1-160000.2.2).

CVE-2025-1149 Severity: Moderate CVSS3 score: 0.0

Description: A vulnerability was found in GNU Binutils 2.43. It has been classified as problematic. This affects the function xstrdup of the file libiberty/xmalloc.c of the component ld. The manipulation leads to memory leak. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-1178 Severity: Moderate CVSS3 score: 0.0

Description: A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. Affected by this vulnerability is the function bfd_putl64 of the file libbfd.c of the component ld. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The identifier of the patch is 75086e9de1707281172cc77f178e7949a4414ed0. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-1179 Severity: Moderate CVSS3 score: 0.0

Description: A vulnerability was found in GNU Binutils 2.43. It has been rated as critical. Affected by this issue is the function bfd_putl64 of the file bfd/libbfd.c of the component ld. The manipulation leads to memory corruption. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. It is recommended to upgrade the affected component. The code maintainer explains, that "[t]his bug has been fixed at some point between the 2.43 and 2.44 releases".

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-1181 Severity: Moderate CVSS3 score: 0.0

Description: A vulnerability classified as critical was found in GNU Binutils 2.43. This vulnerability affects the function _bfd_elf_gc_mark_rsec of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 931494c9a89558acb36a03a340c01726545eef24. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-38322 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel: Fix crash in icl_update_topdown_event()The perf_fuzzer found a hard-lockup crash on a RaptorLake machine: Oops: general protection fault, maybe for address 0xffff89aeceab400: 0000 CPU: 23 UID: 0 PID: 0 Comm: swapper/23 Tainted: [W]=WARN Hardware name: Dell Inc. Precision 9660/0VJ762 RIP: 0010:native_read_pmc+0x7/0x40 Code: cc e8 8d a9 01 00 48 89 03 5b cd cc cc cc cc 0f 1f ... RSP: 000:fffb03100273de8 EFLAGS: 00010046 .... Call Trace: icl_update_topdown_event+0x165/0x190 ? ktime_get+0x38/0xd0 intel_pmu_read_event+0xf9/0x210 __perf_event_read+0xf9/0x210CPUs 16-23 are E-core CPUs that don't support the perf metrics feature.The icl_update_topdown_event() should not be invoked on these CPUs.It's a regression of commit: f9bdf1f95339 ("perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read")The bug introduced by that commit is that the is_topdown_event() functionis mistakenly used to replace the is_topdown_count() call to check if thetopdown functions for the perf metrics feature should be invoked.Fix it.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-38339 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/bpf: fix JIT code size calculation of bpf trampolinearch_bpf_trampoline_size() provides JIT size of the BPF trampolinebefore the buffer for JIT'ing it is allocated. The total number ofinstructions emitted for BPF trampoline JIT code depends on wherethe final image is located. So, the size arrived at with the dummypass in arch_bpf_trampoline_size() can vary from the actual sizeneeded in arch_prepare_bpf_trampoline(). When the instructionsaccounted in arch_bpf_trampoline_size() is less than the number ofinstructions emitted during the actual JIT compile of the trampoline,the below warning is produced: WARNING: CPU: 8 PID: 204190 at arch/powerpc/net/bpf_jit_comp.c:981 __arch_prepare_bpf_trampoline.isra.0+0xd2c/0xdccwhich is: /* Make sure the trampoline generation logic doesn't overflow */ if (image && WARN_ON_ONCE(&image[ctx->idx] > (u32 *)rw_image_end - BPF_INSN_SAFETY)) {So, during the dummy pass, instead of providing some arbitrary imagelocation, account for maximum possible instructions if and when thereis a dependency with image location for JIT'ing.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39739 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/arm-smmu-qcom: Add SM6115 MDSS compatibleAdd the SM6115 MDSS compatible to clients compatible list, as it alsoneeds that workaround.Without this workaround, for example, QRB4210 RB2 which is based onSM4250/SM6115 generates a lot of smmu unhandled context faults duringboot:arm_smmu_context_fault: 116854 callbacks suppressedarm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1]arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420and also failed initialisation of lontium lt9611uxc, gpu and dpu isobserved:(binding MDSS components triggered by lt9611uxc have failed) ------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_vma_init+0x150/0x18c [msm] lr : msm_gem_vma_init+0x150/0x18c [msm] sp : ffff80008144b280 ... Call trace: msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0/0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22 msm_dpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39798 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix the setting of capabilities when automounting a new filesystemCapabilities cannot be inherited when we cross into a new filesystem.They need to be reset to the minimal defaults, and then probed foragain.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-39801 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: Remove WARN_ON for device endpoint command timeoutsThis commit addresses a rarely observed endpoint command timeoutwhich causes kernel panic due to warn when 'panic_on_warn' is enabledand unnecessary call trace prints when 'panic_on_warn' is disabled.It is seen during fast software-controlled connect/disconnect testcases.The following is one such endpoint command timeout that we observed:1. Connect =======->dwc3_thread_interrupt ->dwc3_ep0_interrupt ->configfs_composite_setup ->composite_setup ->usb_ep_queue ->dwc3_gadget_ep0_queue ->__dwc3_gadget_ep0_queue ->__dwc3_ep0_do_control_data ->dwc3_send_gadget_ep_cmd2. Disconnect ==========->dwc3_thread_interrupt ->dwc3_gadget_disconnect_interrupt ->dwc3_ep0_reset_state ->dwc3_ep0_end_control_data ->dwc3_send_gadget_ep_cmdIn the issue scenario, in Exynos platforms, we observed that controltransfers for the previous connect have not yet been completed and endtransfer command sent as a part of the disconnect sequence andprocessing of USB_ENDPOINT_HALT feature request from the host timeout.This maybe an expected scenario since the controller is processing EPcommands sent as a part of the previous connect. It maybe better toremove WARN_ON in all places where device endpoint commands are sent toavoid unnecessary kernel panic due to warn.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.6.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40102 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Prevent access to vCPU events before initAnother day, another syzkaller bug. KVM erroneously allows userspace topend vCPU events for a vCPU that hasn't been initialized yet, leading toKVM interpreting a bunch of uninitialized garbage for routing /injecting the exception.In one case the injection code and the hyp disagree on whether the vCPUhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)Reject the ioctls outright as no sane VMM would call these beforeKVM_ARM_VCPU_INIT anyway. Even if it did the exception would've beenthrown away by the eventual reset of the vCPU's state.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.8.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2025-40104 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:ixgbevf: fix mailbox API compatibility by negotiating supported featuresThere was backward compatibility in the terms of mailbox API. Variousdrivers from various OSes supporting 10G adapters from Intel portfoliocould easily negotiate mailbox API.This convention has been broken since introducing API 1.4.Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added supportfor IPSec which is specific only for the kernel ixgbe driver. None of therest of the Intel 10G PF/VF drivers supports it. And actually lack ofsupport was not included in the IPSec implementation - there were no suchcode paths. No possibility to negotiate support for the feature wasintroduced along with introduction of the feature itself.Commit 339f28964147 ("ixgbevf: Add support for new mailbox communicationbetween PF and VF") increasing API version to 1.5 did the same - itintroduced code supported specifically by the PF ESX driver. It altered APIversion for the VF driver in the same time not touching the versiondefined for the PF ixgbe driver. It led to additional discrepancies,as the code provided within API 1.6 cannot be supported for Linux ixgbedriver as it causes crashes.The issue was noticed some time ago and mitigated by Jake within the commitd0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5").As a result we have regression for IPsec support and after increasing APIto version 1.6 ixgbevf driver stopped to support ESX MBX.To fix this mess add new mailbox op asking PF driver about supportedfeatures. Basing on a response determine whether to set support for IPSecand ESX-specific enhanced mailbox.New mailbox op, for compatibility purposes, must be added within new APIrevision, as API version of OOT PF & VF drivers is already increased to1.6 and doesn't incorporate features negotiate op.Features negotiation mechanism gives possibility to be extended with newfeatures when needed in the future.

Packages affected:

cluster-md-kmp-default < 6.12.0-160000.7.1 (version in image is 6.12.0-160000.5.1).
SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).

CVE-2026-0943 Severity: Moderate CVSS3 score: None

Description: HarfBuzz::Shaper versions before 0.032 for Perl contains a bundled library with a null pointer dereference vulnerability. Versions before 0.032 contain HarfBuzz 8.4.0 or earlier bundled as hb_src.tar.gz in the source tarball, which is affected by CVE-2026-22693.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
libharfbuzz-gobject0 > 0-0 (version in image is 11.0.0-160000.2.2).

CVE-2025-1148 Severity: Low CVSS3 score: 0.0

Description: A vulnerability was found in GNU Binutils 2.43 and classified as problematic. Affected by this issue is the function link_order_scan of the file ld/ldelfgen.c of the component ld. The manipulation leads to memory leak. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-1151 Severity: Low CVSS3 score: 0.0

Description: A vulnerability was found in GNU Binutils 2.43. It has been rated as problematic. This issue affects the function xmemdup of the file xmemdup.c of the component ld. The manipulation leads to memory leak. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-1152 Severity: Low CVSS3 score: 0.0

Description: A vulnerability classified as problematic has been found in GNU Binutils 2.43. Affected is the function xstrdup of the file xstrdup.c of the component ld. The manipulation leads to memory leak. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-1153 Severity: Low CVSS3 score: 0.0

Description: A vulnerability classified as problematic was found in GNU Binutils 2.43/2.44. Affected by this vulnerability is the function bfd_set_format of the file format.c. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. Upgrading to version 2.45 is able to address this issue. The identifier of the patch is 8d97c1a53f3dc9fd8e1ccdb039b8a33d50133150. It is recommended to upgrade the affected component.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-1180 Severity: Low CVSS3 score: 0.0

Description: A vulnerability classified as problematic has been found in GNU Binutils 2.43. This affects the function _bfd_elf_write_section_eh_frame of the file bfd/elf-eh-frame.c of the component ld. The manipulation leads to memory corruption. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
binutils < 2.45-160000.1.1 (version in image is 2.43-160000.2.2).

CVE-2025-1377 Severity: Low CVSS3 score: 0.0

Description: A vulnerability, which was classified as problematic, has been found in GNU elfutils 0.192. This issue affects the function gelf_getsymshndx of the file strip.c of the component eu-strip. The manipulation leads to denial of service. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is fbf1df9ca286de3323ae541973b08449f8d03aba. It is recommended to apply a patch to fix this issue.

Packages affected:

SLES_SAP-release == 16.0 (version in image is 16.0-160000.39.1).
elfutils > 0-0 (version in image is 0.192-160000.2.2).

CVE scan

Summary of CVEs affecting the image: