suse-sles-15-sp4-chost-byos-v20260701-arm64 CVE scan on 2026-07-02T07:01:20+00:00

CVE-2026-11940 Severity: Critical CVSS3 score: 9.8

Description: tarfile.extractall() with the 'data' or 'tar' filter could be bypassed by a crafted archive where a hardlink references a symlink stored at a deeper name than the hardlink itself. The extraction fallback validated the symlink at it's archived location but recreated it at the hardlink's shallowerpath, letting a relative target the filter judged contained escape the destination directory. This allowed a malicious tar archive to create a symlink pointing outside the destination, enabling out-of-destination file reads or writes. This was an incomplete fix of CVE-2025-4330.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

CVE-2026-31629 Severity: Important CVSS3 score: 8.8

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: llcp: add missing return after LLCP_CLOSED checksIn nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socketstate is LLCP_CLOSED, the code correctly calls release_sock() andnfc_llcp_sock_put() but fails to return. Execution falls through tothe remainder of the function, which calls release_sock() andnfc_llcp_sock_put() again. This results in a double release_sock()and a refcount underflow via double nfc_llcp_sock_put(), leading toa use-after-free.Add the missing return statements after the LLCP_CLOSED branchesin both functions to prevent the fall-through.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.222.1 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31709 Severity: Important CVSS3 score: 8.8

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: validate the whole DACL before rewriting it in cifsaclbuild_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from aserver-supplied dacloffset and then use the incoming ACL to rebuild thechmod/chown security descriptor.The original fix only checked that the struct smb_acl header fits beforereading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediateheader-field OOB read, but the rewrite helpers still walk ACEs based onpdacl->num_aces with no structural validation of the incoming DACL body.A malicious server can return a truncated DACL that still contains aheader, claims one or more ACEs, and then drivereplace_sids_and_copy_aces() or set_chmod_dacl() past the validatedextent while they compare or copy attacker-controlled ACEs.Factor the DACL structural checks into validate_dacl(), extend them tovalidate each ACE against the DACL bounds, and use the shared validatorbefore the chmod/chown rebuild paths. parse_dacl() reuses the samevalidator so the read-side parser and write-side rewrite paths agree onwhat constitutes a well-formed incoming DACL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-44932 Severity: Important CVSS3 score: 8.8

Description: Passing of unsanitized strings from DHCP replies into the wicked dhcp client before wicked 0.6.79 could be used by attackers operating a malicious DHCP server to execute code on the local machine.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
wicked < 0.6.79-150400.3.39.1 (version in image is 0.6.77-150400.3.36.1).

CVE-2026-46113 Severity: Important CVSS3 score: 8.8

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Fix shadow paging use-after-free due to unexpected GFNThe shadow MMU computes GFNs for direct shadow pages using sp->gfn plusthe SPTE index. This assumption breaks for shadow paging if the guestpage tables are modified between VM entries (similar to commitaad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE evenwhen creating an MMIO SPTE", 2026-03-27). The flow is as follows:- a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous).- the PDE mapping is changed from outside the guest.- the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped.- the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3.- any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED).The underlying issue is that KVM's walking of shadow PTEs assumes thatif a SPTE is present when KVM wants to install a non-leaf SPTE, then theexisting kvm_mmu_page must be for the correct gfn. Because the only wayfor the gfn to be wrong is if KVM messed up and failed to zap a SPTE...which shouldn't happen, but *actually* only happens in response to aguest write.That bug dates back literally forever, as even the first version of KVMassumes that the GFN matches and walks into the "wrong" shadow page.However, that was only an imprecision until 2032a93d66fa ("KVM: MMU:Don't allocate gfns page for direct mmu pages") came along.Fix it by checking for a target gfn mismatch and zapping the existingSPTE. That way the old SP and rmap entries are gone, KVM installsthe rmap in the right location, and everyone is happy.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.222.1 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53488 Severity: Important CVSS3 score: 8.8

Description: Unknown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
containerd > 0-0 (version in image is 1.7.29-150000.132.1).

CVE-2026-53492 Severity: Important CVSS3 score: 8.8

Description: Unknown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
containerd > 0-0 (version in image is 1.7.29-150000.132.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: icmp: validate reply type before using icmp_pointersExtended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type.That value is outside the range covered by icmp_pointers[], which onlydescribes the traditional ICMP types up to NR_ICMP_TYPES.Avoid consulting icmp_pointers[] for reply types outside that range, anduse array_index_nospec() for the remaining in-range lookup. Normal ICMPreplies keep their existing behavior unchanged.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: require Ethernet MAC header before using eth_hdr()`ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and`hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)`after either assuming that the skb is associated with an Ethernetdevice or checking only that the `ETH_HLEN` bytes at`skb_mac_header(skb)` lie between `skb->head` and `skb->data`.Make these paths first verify that the skb is associated with anEthernet device, that the MAC header was set, and that it spans atleast a full Ethernet header before accessing `eth_hdr(skb)`.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO pathsmb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTLand the default QUERY_INFO path. The QUERY_INFO branch clampsqi.input_buffer_length to the server-reported OutputBufferLength and thencopies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, butit never verifies that the flexible-array payload actually fits withinrsp_iov[1].iov_len.A malicious server can return OutputBufferLength larger than the actualQUERY_INFO response, causing copy_to_user() to walk past the responsebuffer and expose adjacent kernel heap to userspace.Guard the QUERY_INFO copy with a bounds check on the actual Bufferpayload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length)rather than an open-coded addition so the guard cannot overflow on32-bit builds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: move wake reason storage into validated event handlershci_store_wake_reason() is called from hci_event_packet() immediatelyafter stripping the HCI event header but before hci_event_func()enforces the per-event minimum payload length from hci_ev_table.This means a short HCI event frame can reach bacpy() before any boundscheck runs.Rather than duplicating skb parsing and per-event length checks insidehci_store_wake_reason(), move wake-address storage into the individualevent handlers after their existing event-length validation hassucceeded. Convert hci_store_wake_reason() into a small helper that onlystores an already-validated bdaddr while the caller holds hci_dev_lock().Use the same helper after hci_event_func() with a NULL address topreserve the existing unexpected-wake fallback semantics when novalidated event handler records a wake address.Annotate the helper with __must_hold(&hdev->lock) and addlockdep_assert_held(&hdev->lock) so future call paths keep the lockcontract explicit.Call the helper from hci_conn_request_evt(), hci_conn_complete_evt(),hci_sync_conn_complete_evt(), le_conn_complete_evt(),hci_le_adv_report_evt(), hci_le_ext_adv_report_evt(),hci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), andhci_le_past_received_evt().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string. While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods: Use a validating interceptor (recommended mitigation); infrastructure-level normalization; and/or policy hardening.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
containerd < 1.7.29-150000.137.1 (version in image is 1.7.29-150000.132.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix double-free in tipc_buf_append()tipc_msg_validate() can potentially reallocate the skb it is validating,freeing the old one. In tipc_buf_append(), it was being called with apointer to a local variable which was a copy of the caller's skbpointer.If the skb was reallocated and validation subsequently failed, the errorhandling path would free the original skb pointer, which had alreadybeen freed, leading to double-free.Fix this by checking if head now points to a newly allocated reassembledskb. If it does, reassign *headbuf for later freeing operations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: jq is a command-line JSON processor. Prior to 1.8.2, on 32bit system, jvp_string_append has a chance of integer/multiple overflowing and then causing a massive buffer overrun. This vulnerability is fixed in 1.8.2.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
jq > 0-0 (version in image is 1.6-150000.3.12.1).

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

Description: socat versions 1.8.0.0 through 1.8.1.1 contain a heap-based buffer overflow vulnerability that allows a malicious SOCKS5 proxy server to overwrite adjacent heap memory by exploiting a sign-extension flaw in the DOMAINNAME reply parser. During connection setup, the domain name length byte is read through a signed char field causing a negative bytes_to_read value that is implicitly converted to size_t, resulting in an unbounded heap write into the 262-byte reply buffer with attacker-controlled size and content.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
socat > 0-0 (version in image is 1.8.0.0-150400.14.6.1).

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

Description: Use-after-free (UAF) was possible in the `lzma.LZMADecompressor`, `bz2.BZ2Decompressor`, and `gzip.GzipFile` when a memory allocation fails with a `MemoryError` and the decompression instance is re-used. This scenario can be triggered if the process is under memory pressure. The fix cleans up the dangling pointer in this specific error condition.The vulnerability is only present if the program re-uses decompressor instances across multiple decompression calls even after a `MemoryError` is raised during decompression. Using the helper functions to one-shot decompress data such as `lzma.decompress()`, `bz2.decompress()`, `gzip.decompress()`, and `zlib.decompress()` are not affected as a new decompressor instance is used per call. If the decompressor instance is not re-used after an error condition, this usage is similarly not vulnerable.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

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

Description: pip would treat console_scripts and gui_scripts as paths instead of file names without sanitizing the resolved absolute path to the installation directory, leading to entry points being installed outside the installation directory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).

CVE-2023-4750 Severity: Important CVSS3 score: 7.8

Description: Use After Free in GitHub repository vim/vim prior to 9.0.1857.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
vim > 0-0 (version in image is 9.2.0280-150000.5.89.1).

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

Description: SQLite before 3.53.2 contains memory corruption vulnerabilities in the FTS5 full-text search extension that allow attackers to cause process crashes, memory exhaustion, or arbitrary code execution by supplying a crafted database with malformed FTS5 page data. Attackers can trigger an out-of-bounds read in fts5LeafSeek() via an attacker-controlled loop bound and a heap buffer overflow write in fts5ChunkIterate() through a crafted continuation page causing an integer underflow, exploitable when an FTS5 MATCH query is executed against the malicious database.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libsqlite3-0 < 3.53.2-150000.3.42.1 (version in image is 3.51.3-150000.3.39.1).

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

Description: SQLite before 3.53.2 contains a heap-based buffer overflow vulnerability in the FTS5 full-text search extension that allows attackers to cause a crash or execute arbitrary code by supplying a crafted database with malicious continuation page metadata specifying a szLeaf value smaller than 4. Attackers can trigger an integer underflow in fts5ChunkIterate() causing an inflated remaining byte count during FTS5 MATCH query processing, leading to a heap buffer overflow of attacker-controlled data in applications compiled with SQLITE_ENABLE_FTS5.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libsqlite3-0 < 3.53.2-150000.3.42.1 (version in image is 3.51.3-150000.3.39.1).

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

Description: A flaw was found in the cifs-utils package where the cifs.upcall helper fails to securely drop its root privileges before looking up user information inside a user-controlled environment. A local, low privileged attacker can exploit this by using a crafted request_key payload to trick the root-owned helper into entering a custom environment (namespace) containing a malicious NSS module. This forces the system to load the attacker's controlled NSS Module and configuration, allowing them to execute arbitrary commands as the root user, elevating their privileges and fully compromising the system.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
cifs-utils < 6.15-150400.3.21.1 (version in image is 6.15-150400.3.18.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: smscufx: properly copy ioctl memory to kernelspaceThe UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data fromuserspace to kernelspace, and instead directly references the memory,which can cause problems if invalid data is passed from userspace. Fixthis all up by correctly copying the memory before accessing it withinthe kernel.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_uac1_legacy: validate control request sizef_audio_complete() copies req->length bytes into a 4-byte stackvariable: u32 data = 0; memcpy(&data, req->buf, req->length);req->length is derived from the host-controlled USB request path,which can lead to a stack out-of-bounds write.Validate req->actual against the expected payload size for thesupported control selectors and decode only the expected amountof data.This avoids copying a host-influenced length into a fixed-sizestack object.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:usb: usbtmc: Flush anchored URBs in usbtmc_releaseWhen calling usbtmc_release, pending anchored URBs must be flushed orkilled to prevent use-after-free errors (e.g. in the HCD givebackpath). Call usbtmc_draw_down() to allow anchored URBs to be completed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.222.1 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set()The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8bytes via memset without checking the buffer size parameter. This allowsunprivileged userspace to trigger an out-of bounds kernel memory writeby passing a small buffer, leading to potential privilegeescalation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.222.1 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-freedlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pagesto userspace but sets no vm_ops on the VMA. This means the kernel cannottrack active mmaps. When dlfb_realloc_framebuffer() replaces the backingbuffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated.On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pageswhile userspace PTEs still reference them, resulting in a use-after-free:the process retains read/write access to freed kernel pages.Add vm_operations_struct with open/close callbacks that maintain anatomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(),check mmap_count and return -EBUSY if the buffer is currently mapped,preventing buffer replacement while userspace holds stale PTEs.Tested with PoC using dummy_hcd + raw_gadget USB device emulation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:rtmutex: Use waiter::task instead of current in remove_waiter()remove_waiter() is used by the slowlock paths, but it is also used forproxy-lock rollback in rt_mutex_start_proxy_lock() when invoked fromfutex_requeue().In the latter case waiter::task is not current, but remove_waiter()operates on current for the dequeue operation. That results in severalproblems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter taskUse waiter::task instead of current in all related operations inremove_waiter() to cure those problems.[ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the changelog ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.222.1 (version in image is 5.14.21-150400.24.219.1).

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

Description: `PluginScript` attempts to `chroot` the plugin to the `repoManagerRoot`, this root is frequently `/` (the system root) in standard configurations or when using `--root`. If the chroot target is `/`, it is a no-op, allowing the traversed path to execute host binaries (like `/bin/bash`) with root privileges.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libsolv-tools < 0.7.39-150400.3.46.1 (version in image is 0.7.34-150400.3.41.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/exynos: vidi: fix to avoid directly dereferencing user pointerIn vidi_connection_ioctl(), vidi->edid(user pointer) is directlydereferenced in the kernel.This allows arbitrary kernel memory access from the user space, so insteadof directly accessing the user pointer in the kernel, we should modify itto copy edid to kernel memory using copy_from_user() and use it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix use-after-free in iomap inline data write pathThe inline data buffer head (dibh) is being released prematurely ingfs2_iomap_begin() via release_metapath() while iomap->inline_datastill points to dibh->b_data. This causes a use-after-free wheniomap_write_end_inline() later attempts to write to the inline dataarea.The bug sequence:1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode)3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 04. kswapd reclaims the page (~39ms later in the syzbot report)5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data6. KASAN detects use-after-free write to freed memoryFix by storing dibh in iomap->private and incrementing its refcountwith get_bh() in gfs2_iomap_begin(). The buffer is then properlyreleased in gfs2_iomap_end() after the inline write completes,ensuring the page stays alive for the entire iomap operation.Note: A C reproducer is not available for this issue. The fix is basedon analysis of the KASAN report and code review showing the buffer headis freed before use.[agruenba: Take buffer head reference in gfs2_iomap_begin() to avoidleaks in gfs2_iomap_get() and gfs2_iomap_alloc().]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: defensively unhash xfrm_state lists in __xfrm_state_deleteKASAN reproduces a slab-use-after-free in __xfrm_state_delete()'shlist_del_rcu calls under syzkaller load on linux-6.12.y stable(reproduced on 6.12.47, also reachable via the same code path ontorvalds/master and on the ipsec tree). Nine unique signatures clusterin the xfrm_state lifecycle, the load-bearing one being: BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435 Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_netThe other observed signatures hit the same slab object from__xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOBwrite variant of __xfrm_state_delete, all on the byseq/byspihash chains.__xfrm_state_delete() guards its byseq and byspi unhashes withvalue-based predicates: if (x->km.seq) hlist_del_rcu(&x->byseq); if (x->id.spi) hlist_del_rcu(&x->byspi);while everywhere else in the file (e.g. state_cache, state_cache_input)the safer hlist_unhashed() check is used. xfrm_alloc_spi() setsx->id.spi = newspi inside xfrm_state_lock and then immediately insertsinto byspi, but a path that observes x->id.spi != 0 outside ofxfrm_state_lock can still skip-or-hit the byspi unhash inconsistentlywith whether x is actually on the list. The same holds for x->km.seqversus byseq, and the bydst/bysrc unhashes have no predicate at all,so a second __xfrm_state_delete() on the same object writes throughLIST_POISON pprev.The defensive change here: - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc(). - Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields.Empirical verification: applied this patch on top of v6.12.47, rebuilt,and re-ran the same syzkaller harness for 1h16m on a previously-crashyconfiguration that produced ~100 hits each of slab-use-after-freeRead in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in__xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfoconfirms the xfrm_state slab is actively allocated and freed duringthe run (~143 KiB resident), so the fuzzer is still exercising thosecode paths -- they just no longer crash.Reproduction: - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrm_state lifecycle

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ip6_gre: Use cached t->net in ip6erspan_changelink().After commit 5e72ce3e3980 ("net: ipv6: Use link netns in newlink() ofrtnl_link_ops"), ip6erspan_newlink() correctly resolves the per-netnsip6gre hash via link_net. ip6erspan_changelink() was not converted inthat series and still uses dev_net(dev), which diverges from thedevice's creation netns after IFLA_NET_NS_FD migration.This re-inserts the tunnel into the wrong per-netns hash. Theoriginal netns keeps a stale entry. When that netns is laterdestroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing aslab-use-after-free reported by KASAN, followed by a kernel BUG atnet/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify().Reachable from an unprivileged user namespace (unshare --user--map-root-user --net).ip6gre_changelink() earlier in the same file already uses the cachedt->net; only ip6erspan_changelink() has the wrong shape.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: validate SVM ioctl nattr against buffer sizeValidate nattr field against the buffer size, preventingout-of-bounds buffer access via user-controlled attribute count.(cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: reject userspace cifs.spnego descriptionscifs.spnego key descriptions contain authority-bearing fields such aspid, uid, creduid, and upcall_target that cifs.upcall treats askernel-originating inputs. However, userspace can also create keys ofthis type through request_key(2) or add_key(2), allowing those fields tobe supplied without CIFS origin.Only accept cifs.spnego descriptions while CIFS is using its privatespnego_cred to request the key.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.222.1 (version in image is 5.14.21-150400.24.219.1).

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

Description: Vim is an open source, command line text editor. Prior to 9.2.0479, a command injection vulnerability exists in tar#Vimuntar() inruntime/autoload/tar.vim when decompressing .tgz archives on Unix-like systems. The function builds :!gunzip and :!gzip -d commands using shellescape(tartail) without the {special} flag, allowing a crafted archive filename to trigger Vim cmdline-special expansion and execute shell commands in the user's context. This vulnerability is fixed in 9.2.0479.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim < 9.2.0530-150000.5.94.1 (version in image is 9.2.0280-150000.5.89.1).

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

Description: A flaw was found in libsolv. This heap buffer overflow occurs during the decompression of attacker-controlled compressed data within `.solv` files due to insufficient input validation. An attacker can provide a specially crafted `.solv` file, which, when processed by a vulnerable application, can lead to out-of-bounds memory access. This could result in information disclosure, alteration of program execution, or a denial of service.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libsolv-tools > 0-0 (version in image is 0.7.34-150400.3.41.1).

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

Description: Vim is an open source, command line text editor. Prior to version 9.2.0561, the Python omni-completion script in python3complete.vim for Vim with the +python3 interpreter enabled (and the legacy pythoncomplete.vim for builds with the +python interpreter) executes the import and from statements found in the current buffer through Python's import machinery. Because the buffer's working directory is on sys.path, opening a hostile .py file with a sibling Python package and invoking omni-completion runs that package's top-level code as the editing user. This issue has been patched in version 9.2.0561.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.2.0280-150000.5.89.1).

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

Description: Vim is an open source, command line text editor. Prior to version 9.2.0597, Vim's Python omni-completion executes reconstructed function and class definitions from the current buffer with exec() as part of populating the completion dictionary. Python evaluates function default values, parameter annotations, and class base expressions at definition time, so a hostile buffer can execute attacker-controlled Python expressions during omni-completion. The existing g:pythoncomplete_allow_import mitigation (GHSA-52mc-rq6p-rc7c) does not cover this path, because the attacker-controlled code is not a harvested import/from statement. This issue has been patched in version 9.2.0597.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.2.0280-150000.5.89.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: fix tp_meter counter underflow during shutdownbatadv_tp_sender_shutdown() unconditionally decrements the "sending"atomic counter. If multiple paths (e.g. timeout, user cancel, andnormal finish) call this function, the counter can underflow to -1.Since the sender logic treats any non-zero value as "still sending",a negative value causes the sender kthread to loop indefinitely.This leads to a use-after-free when the interface is removed whilethe zombie thread is still active.Fix this by using atomic_xchg() to ensure the counter only transitionsfrom 1 to 0 once.[sven: added missing change in batadv_tp_send]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipc: limit next_id allocation to the valid ID rangeThe checkpoint/restore sysctl path can request the next SysV IPC idthrough ids->next_id. ipc_idr_alloc() currently forwards that request toidr_alloc() with an open-ended upper bound.If the valid tail of the SysV IPC id space is full, the allocation canspill beyond ipc_mni. The returned SysV IPC id still uses the normalindex encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for theobject.The bug is in ipc_idr_alloc() in the checkpoint/restore path.1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...)2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range.3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index.5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer.6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory.Prevent this by bounding the requested allocation to ipc_mni so thecheckpoint/restore path fails once the valid range is exhausted.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Reject wrapped offset in kvm_reset_dirty_gfn()kvm_reset_dirty_gfn() guards the gfn range with if (!memslot || (offset + __fls(mask)) >= memslot->npages) return;but offset is u64 and the addition is unchecked. The check can besilently bypassed by a u64 wrap.The dirty ring backing those entries is MAP_SHARED atKVM_DIRTY_LOG_PAGE_OFFSET of the vcpu fd, so the VMM can rewrite theslot and offset fields of any entry between when the kernel pushesthem and when KVM_RESET_DIRTY_RINGS consumes them. On reset,kvm_dirty_ring_reset() re-reads the values via READ_ONCE() and feedsthem straight back into this check; only the flags handshake istreated as the handover, the slot/offset payload is taken on trust.Crafting two entries entry[i].offset = 0xffffffffffffffc1 entry[i+1].offset = 0makes the coalescing loop in kvm_dirty_ring_reset() compute delta = (s64)(0 - 0xffffffffffffffc1) = 63which falls in [0, BITS_PER_LONG), so it folds entry[i+1] into theexisting mask by setting bit 63. The trailing kvm_reset_dirty_gfn()call then sees offset = 0xffffffffffffffc1 and __fls(mask) = 63;the sum is 0 in u64 and the bounds check passes.That offset propagates into kvm_arch_mmu_enable_log_dirty_pt_masked()unchanged. On the legacy MMU path -- kvm_memslots_have_rmaps() ==true, i.e. shadow paging, any VM that has allocated shadow roots, ora write-tracked slot -- it reaches gfn_to_rmap(), which indexesslot->arch.rmap[0][] with a near-U64_MAX gfn. That is anout-of-bounds load of a kvm_rmap_head, followed by a conditionalclear of PT_WRITABLE_MASK in whatever the loaded pointer points at.The path is reachable from any process holding /dev/kvm.Range-check offset on its own first, so the addition cannot wrap.memslot->npages is bounded well below U64_MAX, so once offset

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Cap AEAD AD length to 0x80000000In order to prevent arithmetic overflows when checking the TXbuffer size, cap the associated data length to 0x80000000.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, arm64: Fix off-by-one in check_imm signed range checkcheck_imm(bits, imm) is used in the arm64 BPF JIT to verify thata branch displacement (in arm64 instruction units) fits into thesigned N-bit immediate field of a B, B.cond or CBZ/CBNZ encodingbefore it is handed to the encoder. The macro currently tests for(imm > 0 && imm >> bits) || (imm < 0 && ~imm >> bits) which admitsvalues in [-2^N, 2^N) - effectively a signed (N+1)-bit range. Asigned N-bit field only holds [-2^(N-1), 2^(N-1)), so the checkadmits one extra bit of range on each side.In particular, for check_imm19(), values in [2^18, 2^19) slip pastthe check but do not fit into the 19-bit signed imm19 field ofB.cond. aarch64_insn_encode_immediate() then masks the raw valueinto the 19-bit field, setting bit 18 (the sign bit) and flippinga forward branch into a backward one. Same class of issue existsfor check_imm26() and the B/BL encoding. Shift by (bits - 1)instead of bits so the actual signed N-bit range is enforced.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/komeda: fix integer overflow in AFBC framebuffer size checkThe AFBC framebuffer size validation calculates the minimum requiredbuffer size by adding the AFBC payload size to the framebuffer offset.This addition is performed without checking for integer overflow.If the addition oveflows, the size check may incorrectly succed andallow userspace to provide an undersized drm_gem_object, potentiallyleading to out-of-bounds memory access.Add usage of check_add_overflow() to safely compute the minimumrequired size and reject the framebuffer if an overflow is detected.This makes the AFBC size validation more robust against malformed.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix same-register dst/src OOB read and pointer leak in sock_opsWhen a BPF sock_ops program accesses ctx fields with dst_reg == src_reg,the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero thedestination register in the !fullsock / !locked_tcp_sock path.Both macros borrow a temporary register to check is_fullsock /is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds thectx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state witha request_sock), dst_reg should be zeroed but is not, leaving the stalectx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer.Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/umem: Fix truncation for block sizes >= 4GWhen the iommu is used the linearization of the mapping can give a singleblock that is very large split across multiple SG entries.When __rdma_block_iter_next() reassembles the split SG entries it isoverflowing the 32 bit stack values and computed the wrong DMA addressesfor blocks after the truncation.Use the right types to hold DMA addresses.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: bail out on template ct in get evalI noticed this issue while looking at a historic syzbot report [1].A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } }The first expression attaches a per-cpu template ct vianft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is allzero, nf_ct_l3num(ct) == 0). The next expression then callsnft_ct_get_eval() on the same skb, treats the template as a real ctand hits the 16-byte memcpy path. With dreg at NFT_REG32_15 thisoverflows past struct nft_regs on the kernel stack; with smallerdreg values it silently clobbers adjacent registers.Reject template ct at the eval entry and in nft_ct_get_fast_eval(),mirroring the check nft_ct_set_eval() already has. Additionally,bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->leninstead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuplebefore pkt_to_tuple() fills in only the protocol-relevant leadingbytes, so the trailing bytes of tuple->{src,dst}.u3.all arewell-defined zero. priv->len is validated at rule load, so thecopy size is now bounded by the destination register rather thanby an untrusted field on the conntrack.[1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: Vim is an open source, command line text editor. Prior to 9.2.0663, a Vimscript code injection vulnerability exists in s:NetrwLocalRmFile() in the netrw plugin (runtime/pack/dist/opt/netrw/autoload/netrw.vim) when deleting a local file from the browser. A filename derived from the buffer's directory listing is interpolated into an Ex command line passed to :execute with only the backslash character escaped, allowing a crafted filename containing a bar (|) to terminate the intended command and execute arbitrary Vimscript, including shell commands via :call system() and :!. This vulnerability is fixed in 9.2.0663.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.2.0280-150000.5.89.1).

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

Description: Vim is an open source, command line text editor. Prior to 9.2.0699, Vim's Python omni-completion (runtime/autoload/python3complete.vim and the legacy pythoncomplete.vim) executes reconstructed function and class definitions from the current buffer with exec() as part of populating the completion dictionary. When reconstructing that source, each scope's docstring is inserted verbatim between triple quotes with no escaping, so a hostile buffer can break out of the triple-quoted literal and execute attacker-controlled Python during omni-completion. This vulnerability is fixed in 9.2.0699.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.2.0280-150000.5.89.1).

CVE-2026-46123 Severity: Important CVSS3 score: 7.7

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: virtio_bt: clamp rx length before skb_putvirtbt_rx_work() calls skb_put(skb, len) where len comes directlyfrom virtqueue_get_buf() with no validation against the buffer weposted to the device. The RX skb is allocated in virtbt_add_inbuf()and exposed to virtio as exactly 1000 bytes via sg_init_one().Checking len against skb_tailroom(skb) is not sufficient becausealloc_skb() can leave more tailroom than the 1000 bytes actuallyhanded to the device. A malicious or buggy backend can thereforereport used.len between 1001 and skb_tailroom(skb), causing skb_put()to include uninitialized kernel heap bytes that were never written bythe device.The same path also accepts len == 0, in which case skb_put(skb, 0)leaves the skb empty but virtbt_rx_handle() still reads the pkt_typebyte from skb->data, consuming uninitialized memory.Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() andsg_init_one(), and gate virtbt_rx_work() on that same constant sothe bound checked matches the buffer actually exposed to the device.Reject used.len == 0 in the same gate so an empty completion canno longer reach virtbt_rx_handle().Use bt_dev_err_ratelimited() because the length value comes from anuntrusted backend that can otherwise flood the kernel log.Same class of bug as commit c04db81cd028 ("net/9p: Fix bufferoverflow in USB transport layer"), which hardened the USB 9ptransport against unchecked device-reported length.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43350 Severity: Important CVSS3 score: 7.6

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: require a full NFS mode SID before reading mode bitsparse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFSmode SID and reads sid.sub_auth[2] to recover the mode bits.That assumes the ACE carries three subauthorities, but compare_sids()only compares min(a, b) subauthorities. A malicious server can returnan ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which stillmatches sid_unix_NFS_mode and then drives the sub_auth[2] read fourbytes past the end of the ACE.Require num_subauth >= 3 before treating the ACE as an NFS mode SID.This keeps the fix local to the special-SID mode path without changingcompare_sids() semantics for the rest of cifsacl.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-38039 Severity: Important CVSS3 score: 7.5

Description: When curl retrieves an HTTP response, it stores the incoming headers so thatthey can be accessed later via the libcurl headers API.However, curl did not have a limit in how many or how large headers it wouldaccept in a response, allowing a malicious server to stream an endless seriesof headers and eventually cause curl to run out of heap memory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.83.1).

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

Description: An issue was discovered in libxml2 before 2.11.7 and 2.12.x before 2.12.5. When using the XML Reader interface with DTD validation and XInclude expansion enabled, processing crafted XML documents can lead to an xmlValidatePopElement use-after-free.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.55.1).

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

Description: Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. In versions on the 4.x branch prior to version 4.0.5, when parsing compact JWS or JWE input, Go JOSE could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of `.` characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. Version 4.0.5 fixes this issue. As a workaround, applications could pre-validate that payloads passed to Go JOSE do not contain an excessive number of `.` characters.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
containerd > 0-0 (version in image is 1.7.29-150000.132.1).

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

Description: When using the "configparser" module to write configuration filescontaining multi-line text values with carriage return characters (\r) theresulting file could be injected with unexpected keys and values if theattacker controls the written value.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

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

Description: A vulnerability has been found in cilium ebpf up to 0.21.0. This affects the function loadRawSpec of the file btf/btf.go of the component LoadCollectionSpec/LoadCollectionSpecFromReader. Such manipulation of the argument offset leads to integer overflow. The attack can only be performed from a local environment. The exploit has been disclosed to the public and may be used. The name of the patch is 533dfc82fd228bfadf42ea7180c39de7d9af47fa. A patch should be applied to remediate this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
containerd > 0-0 (version in image is 1.7.29-150000.132.1).

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

Description: When using the "tarfile" module with a file opened in "streaming mode" (mode="r|") the tarfile module did not properly handle EOF, making archive parsing take exponentially longer.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

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

Description: BIND servers that are configured to use TKEY-based authentication via GSS-API tokens are vulnerable to excessive memory consumption when receiving and processing maliciously-constructed packets. Typically these servers will be found in Active Directory integrated DNS deployments and/or Kerberos-secured DNS environments.This issue affects BIND 9 versions 9.0.0 through 9.16.50, 9.18.0 through 9.18.48, 9.20.0 through 9.20.22, 9.21.0 through 9.21.21, 9.9.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.48-S1, and 9.20.9-S1 through 9.20.22-S1.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
bind-utils < 9.16.50-150400.5.62.1 (version in image is 9.16.50-150400.5.59.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix possible deadlock between unlink and dio_end_io_writeocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,while in ocfs2_dio_end_io_write, it acquires these locks in reverse order.This creates an ABBA lock ordering violation on lock classesocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] andocfs2_file_ip_alloc_sem_key.Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem):ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir ocfs2_expand_inline_dir down_write(&oi->ip_alloc_sem) <- Lock BLock Chain #1 (ip_alloc_sem -> orphan dir inode_lock):ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock ADeadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode)Since ip_alloc_sem is to protect allocation changes, which is unrelatedwith operations in ocfs2_del_inode_from_orphan. So moveocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: unicodedata.normalize() can take excessive CPU time when processingspecially crafted Unicode input containing long runs of combining characterswith alternating Canonical Combining Class values.This affects all normalization forms.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

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

Description: When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
containerd < 1.7.29-150000.137.1 (version in image is 1.7.29-150000.132.1).

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

Description: Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. Prior to 4.1.4 and 3.0.5, decrypting a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key. This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected. This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common. Panics can lead to denial of service. This vulnerability is fixed in 4.1.4 and 3.0.5.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
containerd < 1.7.29-150000.137.1 (version in image is 1.7.29-150000.132.1).

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

Description: In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
openssh < 8.4p1-150300.3.65.1 (version in image is 8.4p1-150300.3.60.1).

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

Description: The iconv() function in the GNU C Library versions 2.43 and earlier may crash due to an assertion failure when converting inputs from the IBM1390 or IBM1399 character sets, which may be used to remotely crash an application.This vulnerability can be trivially mitigated by removing the IBM1390 and IBM1399 character sets from systems that do not need them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glibc < 2.31-150300.101.1 (version in image is 2.31-150300.98.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ip6_tunnel: clear skb2->cb[] in ip4ip6_err()Oskar Kjos reported the following problem.ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was writtenby the IPv6 receive path as struct inet6_skb_parm. icmp_send() passesIPCB(skb2) to __ip_options_echo(), which interprets that cb[] regionas struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoffat offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rrvalue. __ip_options_echo() then reads optlen from attacker-controlledpacket data at sptr[rr+1] and copies that many bytes into dopt->__data,a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE).To fix this we clear skb2->cb[], as suggested by Oskar Kjos.Also add minimal IPv4 header validation (version == 4, ihl >= 5).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.222.1 (version in image is 5.14.21-150400.24.219.1).

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

Description: urllib3 is an HTTP client library for Python. From 1.23 to before 2.7.0, cross-origin redirects followed from the low-level API via ProxyManager.connection_from_url().urlopen(..., assert_same_host=False) still forward these sensitive headers. This vulnerability is fixed in 2.7.0.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311-urllib3 < 2.0.7-150400.7.30.1 (version in image is 2.0.7-150400.7.27.1).

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

Description: Issue summary: A specially crafted PKCS#7 or S/MIME signed message couldtrigger a use-after-free during PKCS#7 signature verification.Impact summary: A use-after-free may result in process crashes, heapcorruption, or potentially remote code execution.When processing a PKCS#7 or S/MIME signed message, if the SignedDatadigestAlgorithms field is present as an empty ASN.1 SET, OpenSSL mayincorrectly free a caller-owned BIO during PKCS7_verify(). A subsequentuse of the BIO by the calling application results in a use-after-freecondition.In the common case this occurs when the application later callsBIO_free() on the BIO originally passed to PKCS7_verify(). Dependingon allocator behavior and application-specific BIO usage patterns, thismay result in a crash or other memory corruption. In some applicationcontexts this may potentially be exploitable for remote code execution.Applications that process PKCS#7 or S/MIME signed messages using OpenSSLPKCS#7 APIs may be affected. Applications using the CMS APIs for thisprocessing are not affected.The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by thisissue, as the affected code is outside the OpenSSL FIPS module boundary.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libopenssl1_1 < 1.1.1l-150400.7.96.2 (version in image is 1.1.1l-150400.7.93.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcvrxe_rcv() currently checks only that the incoming packet is at leastheader_size(pkt) bytes long before payload_size() is used.However, payload_size() subtracts both the attacker-controlled BTH padfield and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZEThis means a short packet can still make payload_size() underflow evenif it includes enough bytes for the fixed headers. Simply requiringheader_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because apacket with a forged non-zero BTH pad can still leave payload_size()negative and pass an underflowed value to later receive-path users.Fix this by validating pkt->paylen against the full minimum lengthrequired by payload_size(): header_size(pkt) + bth_pad(pkt) +RXE_ICRC_SIZE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.222.1 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: bla: prevent use-after-free when deleting claimsWhen batadv_bla_del_backbone_claims() removes all claims for a backbone, itdoes this by dropping the link entry in the hash list. This list entryitself was one of the references which need to be dropped at the same timevia batadv_claim_put().But the batadv_claim_put() must not be done before the last access to theclaim object in this function. Otherwise the claim might be freed alreadyby the batadv_claim_release() function before the list entry was dropped.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option ("b64": false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311-PyJWT < 2.8.0-150400.8.13.1 (version in image is 2.8.0-150400.8.10.1).

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

Description: Unknown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libsolv-tools < 0.7.39-150400.3.46.1 (version in image is 0.7.34-150400.3.41.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: Fix potential out-of-bounds access in crush_decode()A message of type CEPH_MSG_OSD_MAP containing a crush map with at leastone bucket has two fields holding the bucket algorithm. If the valuesin these two fields differ, an out-of-bounds access can occur. This isthe case because the first algorithm field (alg) is used to allocatethe correct amount of memory for a bucket of this type, while the secondalgorithm field inside the bucket (b->alg) is used in the subsequentprocessing.This patch fixes the issue by adding a check that compares alg andb->alg and aborts the processing in case they differ. Furthermore,b->alg is set to 0 in this case, because the destruction of the crushmap also uses this field to determine the bucket type, which can againresult in an out-of-bounds access when trying to free the memory pointedto by the fields of the bucket. To correctly free the memory allocatedfor the bucket in such a case, the corresponding call to kfree is movedfrom the algorithm-specific crush_destroy_bucket functions to thegeneric crush_destroy_bucket().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: Fix potential out-of-bounds access in osdmap_decode()When decoding osd_state and osd_weight from an incoming osdmap inosdmap_decode(), both are decoded for each osd, i.e., map->max_osdtimes. The ceph_decode_need() check only accounts forsizeof(*map->osd_weight) once. This can potentially result in anout-of-bounds memory access if the incoming message is corrupted suchthat the max_osd value exceeds the actual content of the osdmap message.This patch fixes the issue by changing the corresponding part in theceph_decode_need() check to account formap->max_osd*sizeof(*map->osd_weight).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_sip: don't use simple_strtoulReplace unsafe port parsing in epaddr_len(), ct_sip_parse_header_uri(),and ct_sip_parse_request() with a new sip_parse_port() helper thatvalidates each digit against the buffer limit, eliminating the use ofsimple_strtoul() which assumes NUL-terminated strings.The previous code dereferenced pointers without bounds checks aftersip_parse_addr() and relied on simple_strtoul() on non-NUL-terminatedskb data. A port that reaches the buffer limit without a trailingcharacter is also rejected as malformed.Also get rid of all simple_strtoul() usage in conntrack, prefer astricter version instead. There are intentional changes:- Bail out if number is > UINT_MAX and indicate a failure, same for too long sequences. While we do accept 05535 as port 5535, we will not accept e.g. 'sip:10.0.0.1:005060'. While its syntactically valid under RFC 3261, we should restrict this to not waste cycles when presented with malformed packets with 64k '0' characters.- Force base 10 in ct_sip_parse_numerical_param(). This is used to fetch 'expire=' and 'rports='; both are expected to use base-10.- In nf_nat_sip.c, only accept the parsed value if its within the 1k-64k range.- epaddr_len now returns 0 if the port is invalid, as it already does for invalid ip addresses. This is intentional. nf_conntrack_sip performs lots of guesswork to find the right parts of the message to parse. Being stricter could break existing setups. Connection tracking helpers are designed to allow traffic to pass, not to block it.Based on an earlier patch from Jenny Guanni Qu .

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: Multiple flaws have been identified in `named` related to the handling of DNS messages whose CLASS is not Internet (`IN`) - for example, `CHAOS` or `HESIOD`, or DNS messages that specify meta-classes (`ANY` or `NONE`) in the question section. Specially crafted requests reaching the affected code paths - recursion, dynamic updates (`UPDATE`), zone change notifications (`NOTIFY`), or processing of `IN`-specific record types in non-`IN` data - can cause assertion failures in `named`.This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.48, 9.20.0 through 9.20.22, 9.21.0 through 9.21.21, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.48-S1, and 9.20.9-S1 through 9.20.22-S1.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
bind-utils < 9.16.50-150400.5.62.1 (version in image is 9.16.50-150400.5.59.1).

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

Description: `xml.parsers.expat` and `xml.etree.ElementTree` use insufficient entropy for Expat hash-flooding protection, which allows a crafted XML document to trigger hash flooding.\r\n\r\nFully mitigating this vulnerability requires both updating libexpat to 2.8.0 or later and applying this patch.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

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

Description: tarfile.data_filter could be bypassed using crafted link entries, including symlinks with empty or directory-like names, to redirect later archive members outside the intended extraction directory. This allowed a malicious tar archive to cause tarfile.extractall() to write files outside the destination directory, subject to the permissions of the extracting process.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

CVE-2026-11850 Severity: Important CVSS3 score: 7.4

Description: An integer underflow vulnerability was found in MIT krb5 in the berval2tl_data() function in plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c. The function performs an unsigned subtraction (bv_len - 2) without a prior bounds check. When bv_len is 0 or 1, the subtraction wraps to a large value which is then truncated to uint16_t, yielding 0xFFFE (65534) or 0xFFFF (65535). The subsequent malloc succeeds and memcpy reads up to 65534 bytes from a 0-1 byte buffer, resulting in a heap out-of-bounds read.The attack vector involves a malicious or compromised LDAP KDB backend returning a krbExtraData attribute with bv_len < 2, triggering the underflow when the KDC or kadmind reads principal data.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
krb5 > 0-0 (version in image is 1.19.2-150400.3.18.1).

CVE-2026-25707 Severity: Important CVSS3 score: 7.4

Description: A relative path traversal bug problem when processing repository metadata in libzypp before 17.38.10 could be used by remote attackers supplying repositories to overwrite files on the system, leading to denial of service or privilege escalation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libsolv-tools < 0.7.39-150400.3.46.1 (version in image is 0.7.34-150400.3.41.1).

CVE-2026-39821 Severity: Important CVSS3 score: 7.4

Description: The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error. This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
containerd < 1.7.29-150000.137.1 (version in image is 1.7.29-150000.132.1).

CVE-2026-48526 Severity: Important CVSS3 score: 7.4

Description: PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311-PyJWT < 2.8.0-150400.8.13.1 (version in image is 2.8.0-150400.8.10.1).

CVE-2026-54370 Severity: Important CVSS3 score: 7.4

Description: acl before version 2.4.0 contains a time-of-check to time-of-use (TOCTOU) race condition vulnerability that allows local attackers to escalate privileges by replacing a pathname component with a symbolic link between an lstat() check and subsequent symlink-following operations such as stat(), chown(), chmod(), acl_get_file(), and acl_set_file(). Attackers who control a pathname component can redirect file access control list operations to arbitrary files when getfacl, setfacl, or chacl is invoked by a privileged process over an attacker-controlled path, resulting in local privilege escalation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libacl1 > 0-0 (version in image is 2.2.52-4.3.1).

CVE-2026-54371 Severity: Important CVSS3 score: 7.4

Description: attr before version 2.6.0 contains a symlink traversal vulnerability in the getfattr and setfattr utilities that allows local attackers to escalate privileges by replacing a pathname component with a symbolic link during directory hierarchy traversal. Attackers who control a pathname component can redirect getfattr and setfattr operations to arbitrary files by substituting a symlink, leading to local privilege escalation when getfattr or setfattr is invoked by a privileged process over an attacker-controlled path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libacl1 > 0-0 (version in image is 2.2.52-4.3.1).

CVE-2026-43241 Severity: Important CVSS3 score: 7.3

Description: In the Linux kernel, the following vulnerability has been resolved:ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds accessNumber of MW LUTs depends on NTB configuration and can be set to MAX_MWS,This patch protects against invalid index out of bounds access to mw_sizesWhen invalid access print message to user that configuration is not valid.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53016 Severity: Important CVSS3 score: 7.3

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp - copy IV using skcipher ivsizeAF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver.ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller's IVbuffer while RFC3686 skciphers expose an 8-byte IV, so the restoreoverruns the provided buffer.Use crypto_skcipher_ivsize() to copy only the algorithm's IV length.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-44941 Severity: Important CVSS3 score: 7.2

Description: Unknown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libsolv-tools < 0.7.39-150400.3.46.1 (version in image is 0.7.34-150400.3.41.1).

CVE-2026-31613 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix OOB reads parsing symlink error responseWhen a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message()returns success without any length validation, leaving the symlinkparsers as the only defense against an untrusted server.symlink_data() walks SMB 3.1.1 error contexts with the loop test "p ErrorId at offset 4 and p->ErrorDataLength at offset0. When the server-controlled ErrorDataLength advances p to within 1-7bytes of end, the next iteration will read past it. When the matchingcontext is found, sym->SymLinkErrorTag is read at offset 4 fromp->ErrorContextData with no check that the symlink header itself fits.smb2_parse_symlink_response() then bounds-checks the substitute nameusing SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer fromiov_base. That value is computed as sizeof(smb2_err_rsp) +sizeof(smb2_symlink_err_rsp), which is correct only whenErrorContextCount == 0.With at least one error context the symlink data sits 8 bytes deeper,and each skipped non-matching context shifts it further by 8 +ALIGN(ErrorDataLength, 8). The check is too short, allowing thesubstitute name read to run past iov_len. The out-of-bound heap bytesare UTF-16-decoded into the symlink target and returned to userspace viareadlink(2).Fix this all up by making the loops test require the full context headerto fit, rejecting sym if its header runs past end, and bound thesubstitute name against the actual position of sym->PathBuffer ratherthan a fixed offset.Because sub_offs and sub_len are 16bits, the pointer math will notoverflow here with the new greater-than.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31759 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:usb: ulpi: fix double free in ulpi_register_interface() error pathWhen device_register() fails, ulpi_register() calls put_device() onulpi->dev.The device release callback ulpi_dev_release() drops the OF nodereference and frees ulpi, but the current error path inulpi_register_interface() then calls kfree(ulpi) again, causing adouble free.Let put_device() handle the cleanup through ulpi_dev_release() andavoid freeing ulpi again in ulpi_register_interface().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-41991 Severity: Important CVSS3 score: 7.1

Description: GNU gzip contains a vulnerability in the gzexe utility related to insecure temporary file handling. When the mktemp utility is not available in the user's PATH, gzexe falls back to constructing a temporary file path based solely on the process ID (PID). This predictable filename is created without exclusive access or existence checks.A local attacker can pre-create the predicted temporary file path as a symbolic link pointing to an arbitrary file writable by the victim. When gzexe runs, it follows the symlink and overwrites the target file, resulting in a time-of-check to time-of-use (TOCTOU) condition that allows arbitrary file overwrite.This issue has been fixed in the commit 4e6f8b24ab823146ab8776f0b7fe486ab34d4269

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
gzip > 0-0 (version in image is 1.10-150200.10.1).

CVE-2026-43501 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: rpl: reserve mac_len headroom when recompressed SRH growsipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swapsthe next segment into ipv6_hdr->daddr, recompresses, then pulls the oldheader and pushes the new one plus the IPv6 header back. Therecompressed header can be larger than the received one when the swapreduces the common-prefix length the segments share with daddr (CmprI=0,CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes).pskb_expand_head() was gated on segments_left == 0, so on earliersegments the push consumed unchecked headroom. Once skb_push() leavesfewer than skb->mac_len bytes in front of data,skb_mac_header_rebuild()'s call to: skb_set_mac_header(skb, -skb->mac_len);will store (data - head) - mac_len into the u16 mac_header field, whichwraps to ~65530, and the following memmove() writes mac_len bytes ~64KiBpast skb->head.A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a twosegment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after onepass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv.Fix this by expanding the head whenever the remaining room is less thanthe push size plus mac_len, and request that much extra so the rebuiltMAC header fits afterwards.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.222.1 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-46150 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:fanotify: fix false positive on permission eventsfsnotify_get_mark_safe() may return false for a mark on an unrelated group,which results in bypassing the permission check.Fix by skipping over detached marks that are not in the current group.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-46229 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Clear VRAM on allocation to prevent stale data exposureKFD VRAM allocations set AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASEbut not AMDGPU_GEM_CREATE_VRAM_CLEARED, leaving freshly allocatedVRAM with stale data from prior use observable by compute kernels.The GEM ioctl path already sets VRAM_CLEARED for all userspaceallocations via amdgpu_gem_create_ioctl() andamdgpu_mode_dumb_create(). The KFD path was missing this flag,allowing stale page table remnants to leak into user buffers.This causes crashes in RCCL P2P transport where non-zero data inptrExchange/head/tail fields corrupts the protocol handshake.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-4786 Severity: Important CVSS3 score: 7.1

Description: Mitgation of CVE-2026-4519 was incomplete. If the URL contained "%action" the mitigation could be bypassed for certain browser types the "webbrowser.open()" API could have commands injected into the underlying shell. See CVE-2026-4519 for details.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

CVE-2026-49839 Severity: Important CVSS3 score: 7.1

Description: jq is a command-line JSON processor. Prior to 1.8.2,` jq --rawfile` can turn a handled oversized-string error into invalid-state reuse and a real heap out-of-bounds write in assertion-disabled builds. When jv_load_file(raw=1) reads an attacker-controlled file, it repeatedly appends file chunks to the same jv string accumulator. Once jv_string_append_buf() returns jv_invalid_with_msg("String too long"), the raw-file loop does not stop. If the file contains at least one more byte, the next loop iteration appends a new chunk to an object that is already invalid. With assertions enabled this aborts in jvp_string_ptr(). With assertions disabled, the invalid object is interpreted as a string object and ASan reports heap-buffer-overflow. This vulnerability is fixed in 1.8.2.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
jq > 0-0 (version in image is 1.6-150000.3.12.1).

CVE-2026-52909 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:ip6_vti: set netns_immutable on the fallback device.john1988 and Noam Rathaus reported that vti6_init_net() does not set thenetns_immutable flag on the per-netns fallback tunnel device (ip6_vti0).Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel)correctly set this flag during their fallback device initialization toprevent them from being moved to another network namespace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53041 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix listxattr handling when the buffer is full[BUG]If an OCFS2 inode has both inline and block-based xattrs, listxattr()can return a size larger than the caller's buffer when the inline namesconsume that buffer exactly.kernel BUG at mm/usercopy.c:102!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTIRIP: 0010:usercopy_abort+0xb7/0xd0 mm/usercopy.c:102Call Trace: __check_heap_object+0xe3/0x120 mm/slub.c:8243 check_heap_object mm/usercopy.c:196 [inline] __check_object_size mm/usercopy.c:250 [inline] __check_object_size+0x5c5/0x780 mm/usercopy.c:215 check_object_size include/linux/ucopysize.h:22 [inline] check_copy_size include/linux/ucopysize.h:59 [inline] copy_to_user include/linux/uaccess.h:219 [inline] listxattr+0xb0/0x170 fs/xattr.c:926 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x137/0x320 fs/xattr.c:988 __do_sys_listxattr fs/xattr.c:1001 [inline] __se_sys_listxattr fs/xattr.c:998 [inline] __x64_sys_listxattr+0x7f/0xd0 fs/xattr.c:998 ...[CAUSE]Commit 936b8834366e ("ocfs2: Refactor xattr list and removeocfs2_xattr_handler().") replaced the old per-handler list accountingwith ocfs2_xattr_list_entry(), but it kept using size == 0 to detectprobe mode.That assumption stops being true once ocfs2_listxattr() finishes theinline-xattr pass. If the inline names fill the caller buffer exactly,the block-xattr pass runs with a non-NULL buffer and a remaining size ofzero. ocfs2_xattr_list_entry() then skips the bounds check, keepscounting block names, and returns a positive size larger than thesupplied buffer.[FIX]Detect probe mode by testing whether the destination buffer pointer isNULL instead of whether the remaining size is zero.That restores the pre-refactor behavior and matches the OCFS2 getxattrhelpers. Once the remaining buffer reaches zero while more names areleft, the block-xattr pass now returns -ERANGE instead of reporting asize larger than the allocated list buffer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53059 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:dm log: fix out-of-bounds write due to region_count overflowThe local variable region_count in create_log_context() is declared asunsigned int (32-bit), but dm_sector_div_up() returns sector_t (64-bit).When a device-mapper target has a sufficiently large ti->len with a smallregion_size, the division result can exceed UINT_MAX. The truncatedvalue is then used to calculate bitset_size, causing clean_bits,sync_bits, and recovering_bits to be allocated far smaller than neededfor the actual number of regions.Subsequent log operations (log_set_bit, log_clear_bit, log_test_bit) useregion indices derived from the full untruncated region space, causingout-of-bounds writes to kernel heap memory allocated by vmalloc.This can be reproduced by creating a mirror target whose region_countoverflows 32 bits: dmsetup create bigzero --table '0 8589934594 zero' dmsetup create mymirror --table '0 8589934594 mirror \ core 2 2 nosync 2 /dev/mapper/bigzero 0 \ /dev/mapper/bigzero 0'The status output confirms the truncation (sync_count=1 instead of4294967297, because 0x100000001 was truncated to 1): $ dmsetup status mymirror 0 8589934594 mirror 2 254:1 254:1 1/4294967297 ...This leads to a kernel crash in core_in_sync: BUG: scheduling while atomic: (udev-worker)/9150/0x00000000 RIP: 0010:core_in_sync+0x14/0x30 [dm_log] CR2: 0000000000000008 Fixing recursive fault but reboot is needed!Fix by widening the local region_count to sector_t and adding anexplicit overflow check before the value is assigned to lc->region_count.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53071 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rspl2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holdingl2cap_chan_lock(). Every other l2cap_chan_del() caller in the fileacquires the lock first. A remote BLE device can send a craftedL2CAP ECRED reconfiguration response to corrupt the channel listwhile another thread is iterating it.Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(),and l2cap_chan_unlock() and l2cap_chan_put() after, matching thepattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53076 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix OOB in pcpu_init_valueAn out-of-bounds read occurs when copying element from aBPF_MAP_TYPE_CGROUP_STORAGE map to another pcpu map with thesame value_size that is not rounded up to 8 bytes.The issue happens when:1. A CGROUP_STORAGE map is created with value_size not aligned to 8 bytes (e.g., 4 bytes)2. A pcpu map is created with the same value_size (e.g., 4 bytes)3. Update element in 2 with data in 1pcpu_init_value assumes that all sources are rounded up to 8 bytes,and invokes copy_map_value_long to make a data copy, However, theassumption doesn't stand since there are some cases where the sourcemay not be rounded up to 8 bytes, e.g., CGROUP_STORAGE, skb->data.the verifier verifies exactly the size that the source claims, notthe size rounded up to 8 bytes by kernel, an OOB happens when thesource has only 4 bytes while the copy size(4) is rounded up to 8.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53253 Severity: Important CVSS3 score: 7.1

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: bnep: reject short frames before parsingA BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads thepacket type byte immediately and, for control packets, reads the controlopcode and setup UUID-size byte before proving that those bytes arepresent. bnep_rx_control() also dereferences the control opcode withoutrejecting an empty control payload.Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULLreturn gates each dereference. Split the control handler so the framepath can pass an opcode that has already been pulled, and keep thebyte-buffer wrapper for extension control payloads.For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling thesetup payload. struct bnep_setup_conn_req carries destination and sourceservice UUIDs after that byte, each uuid_size bytes, so the parser nowdocuments that tuple explicitly instead of leaving the pull length as anopaque multiplication.Validation reproduced this kernel report:KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790The buggy address belongs to the object at ffff88800c0f7908 which belongsto the cache kmalloc-8 of size 8The buggy address is located 0 bytes to the right of allocated 1-byteregion [ffff88800c0f7908, ffff88800c0f7909)Read of size 1Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-42465 Severity: Important CVSS3 score: 7.0

Description: Sudo before 1.9.15 might allow row hammer attacks (for authentication bypass or privilege escalation) because application logic sometimes is based on not equaling an error value (instead of equaling a success value), and because the values do not resist flips of a single bit.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
sudo > 0-0 (version in image is 1.9.9-150400.4.42.1).

CVE-2023-53995 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv4: fix one memleak in __inet_del_ifa()I got the below warning when do fuzzing test:unregister_netdevice: waiting for bond0 to become free. Usage count = 2It can be repoduced via:ip link add bond0 type bondsysctl -w net.ipv4.conf.bond0.promote_secondaries=1ip addr add 4.117.174.103/0 scope 0x40 dev bond0ip addr add 192.168.100.111/255.255.255.254 scope 0 dev bond0ip addr add 0.0.0.4/0 scope 0x40 secondary dev bond0ip addr del 4.117.174.103/0 scope 0x40 dev bond0ip link delete bond0 type bondIn this reproduction test case, an incorrect 'last_prim' is found in__inet_del_ifa(), as a result, the secondary address(0.0.0.4/0 scope 0x40)is lost. The memory of the secondary address is leaked and the reference ofin_device and net_device is leaked.Fix this problem:Look for 'last_prim' starting at location of the deleted IP and insertingthe promoted IP into the location of 'last_prim'.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/sva: invalidate stale IOTLB entries for kernel address spaceIntroduce a new IOMMU interface to flush IOTLB paging cache entries forthe CPU kernel address space. This interface is invoked from the x86architecture code that manages combined user and kernel page tables,specifically before any kernel page table page is freed and reused.This addresses the main issue with vfree() which is a common occurrenceand can be triggered by unprivileged users. While this resolves theprimary problem, it doesn't address some extremely rare case related tomemory unplug of memory that was present as reserved memory at boot, whichcannot be triggered by unprivileged users. The discussion can be found atthe link below.Enable SVA on x86 architecture since the IOMMU can now receivenotification to flush the paging cache before freeing the CPU kernel pagetable pages.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: libxml2 is vulnerable to multiple stack-based buffer overflows in the xmlcatalog utility when running in --shell mode. The usershell() function processes user input using fixed-size stack buffers without proper bounds checking.By supplying an overly long input line, an attacker can overflow internal buffers (command, arg, and argv) during input parsing. This results in memory corruption within the stack frame.Successful exploitation may cause a crash or potentially allow arbitrary code execution in the context of the xmlcatalog process.This issue has been fixed in the commit c2e233fc.NOTE:The maintainers of this project did not agree that this issue is a vulnerability and considered it a bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.55.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/freeExynos Virtual Display driver performs memory alloc/free operationswithout lock protection, which easily causes concurrency problem.For example, use-after-free can occur in race scenario like this:``` CPU0 CPU1 CPU2 ---- ---- ---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... drm_mode_getconnector() drm_helper_probe_single_connector_modes() vidi_get_modes() if (ctx->raw_edid) // true drm_edid_dup(ctx->raw_edid); if (!drm_edid) // false ... vidi_connection_ioctl() if (vidi->connection) // false drm_edid_free(ctx->raw_edid); // free drm_edid ... drm_edid_alloc(drm_edid->edid) kmemdup(edid); // UAF!! ...```To prevent these vulns, at least in vidi_context, member variables relatedto memory alloc/free should be protected with ctx->lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix use-after-free in nf_tables_addchain()nf_tables_addchain() publishes the chain to table->chains vialist_add_tail_rcu() (in nft_chain_add()) before registering hooks.If nf_tables_register_hook() then fails, the error path callsnft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy()with no RCU grace period in between.This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain.Add synchronize_rcu() between nft_chain_del() and the chain destroyso that all RCU readers -- both dump threads and in-flight packetevaluation -- have finished before the chain is freed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: release flowtable after rcu grace period on errorCall synchronize_rcu() after unregistering the hooks from error path,since a hook that already refers to this flowtable can be alreadyregistered, exposing this flowtable to packet path and nfnetlink_hookcontrol plane.This error path is rare, it should only happen by reaching the maximumnumber hooks or by failing to set up to hardware offload, just callsynchronize_rcu().There is a check for already used device hooks by different flowtablethat could result in EEXIST at this late stage. The hook parser can beupdated to perform this check earlier to this error path really becomesrarely exercised.Uncovered by KASAN reported as use-after-free from nfnetlink_hook pathwhen dumping hooks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

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

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

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: bonding: fix use-after-free in bond_xmit_broadcast()bond_xmit_broadcast() reuses the original skb for the last slave(determined by bond_is_last_slave()) and clones it for others.Concurrent slave enslave/release can mutate the slave list duringRCU-protected iteration, changing which slave is "last" mid-loop.This causes the original skb to be double-consumed (double-freed).Replace the racy bond_is_last_slave() check with a simple indexcomparison (i + 1 == slaves_count) against the pre-snapshot slavecount taken via READ_ONCE() before the loop. This preserves thezero-copy optimization for the last slave while making the "last"determination stable against concurrent list mutations.The UAF can trigger the following crash:==================================================================BUG: KASAN: slab-use-after-free in skb_cloneRead of size 8 at addr ffff888100ef8d40 by task exploit/147CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZYCall Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) 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) Allocated by task 147:Freed by task 147:The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60)Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb>ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb==================================================================

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutexMEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0)queue teardown paths. This can race request object cleanup against vb2queue cancellation and lead to use-after-free reports.We already serialize request queueing against STREAMON/OFF withreq_queue_mutex. Extend that serialization to REQBUFS, and also takethe same mutex in media_request_ioctl_reinit() so REINIT is in thesame exclusion domain.This keeps request cleanup and queue cancellation from running inparallel for request-capable devices.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btintel: serialize btintel_hw_error() with hci_req_sync_lockbtintel_hw_error() issues two __hci_cmd_sync() calls (HCI_OP_RESETand Intel exception-info retrieval) without holdinghci_req_sync_lock(). This lets it race againsthci_dev_do_close() -> btintel_shutdown_combined(), which also runs__hci_cmd_sync() under the same lock. When both paths manipulatehdev->req_status/req_rsp concurrently, the close path may free theresponse skb first, and the still-running hw_error path hits aslab-use-after-free in kfree_skb().Wrap the whole recovery sequence in hci_req_sync_lock/unlock so itis serialized with every other synchronous HCI command issuer.Below is the data race report and the kasan report: BUG: data-race in __hci_cmd_sync_sk / btintel_shutdown_combined read of hdev->req_rsp at net/bluetooth/hci_sync.c:199 by task kworker/u17:1/83: __hci_cmd_sync_sk+0x12f2/0x1c30 net/bluetooth/hci_sync.c:200 __hci_cmd_sync+0x55/0x80 net/bluetooth/hci_sync.c:223 btintel_hw_error+0x114/0x670 drivers/bluetooth/btintel.c:254 hci_error_reset+0x348/0xa30 net/bluetooth/hci_core.c:1030 write/free by task ioctl/22580: btintel_shutdown_combined+0xd0/0x360 drivers/bluetooth/btintel.c:3648 hci_dev_close_sync+0x9ae/0x2c10 net/bluetooth/hci_sync.c:5246 hci_dev_do_close+0x232/0x460 net/bluetooth/hci_core.c:526 BUG: KASAN: slab-use-after-free in sk_skb_reason_drop+0x43/0x380 net/core/skbuff.c:1202 Read of size 4 at addr ffff888144a738dc by task kworker/u17:1/83: __hci_cmd_sync_sk+0x12f2/0x1c30 net/bluetooth/hci_sync.c:200 __hci_cmd_sync+0x55/0x80 net/bluetooth/hci_sync.c:223 btintel_hw_error+0x186/0x670 drivers/bluetooth/btintel.c:260

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:media: em28xx: fix use-after-free in em28xx_v4l2_open()em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock,creating a race with em28xx_v4l2_init()'s error path andem28xx_v4l2_fini(), both of which free the em28xx_v4l2 structand set dev->v4l2 to NULL under dev->lock.This race leads to two issues: - use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler, since the video_device is embedded in the freed em28xx_v4l2 struct. - NULL pointer dereference in em28xx_resolution_set() when accessing v4l2->norm, since dev->v4l2 has been set to NULL.Fix this by moving the mutex_lock() before the dev->v4l2 read andadding a NULL check for dev->v4l2 under the lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:rtnetlink: add missing netlink_ns_capable() check for peer netnsrtnl_newlink() lacks a CAP_NET_ADMIN capability check on the peernetwork namespace when creating paired devices (veth, vxcan,netkit). This allows an unprivileged user with a user namespaceto create interfaces in arbitrary network namespaces, includinginit_net.Add a netlink_ns_capable() check for CAP_NET_ADMIN in the peernamespace before allowing device creation to proceed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: jq is a command-line JSON processor. In 1.8.1 and earlier, the jq bytecode VM's data stack tracks its allocation size in a signed int. When the stack grows beyond ~1 GiB (via deeply nested generator forks), the doubling arithmetic overflows. The wrapped value is passed to realloc and then used for a memmove with attacker-influenced offsets.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
jq > 0-0 (version in image is 1.6-150000.3.12.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: algif_aead - Fix minimum RX size check for decryptionThe check for the minimum receive buffer size did not take thetag size into account during decryption. Fix this by adding therequired extra length.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: remove xfs_attr_leaf_hasnameThe calling convention of xfs_attr_leaf_hasname() is problematic, becauseit returns a NULL buffer when xfs_attr3_leaf_read fails, a valid bufferwhen xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and anon-NULL buffer pointer for an already released buffer whenxfs_attr3_leaf_lookup_int fails with other error values.Fix this by simply open coding xfs_attr_leaf_hasname in the callers, sothat the buffer release code is done by each caller ofxfs_attr3_leaf_read.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix potential race in tcp_v6_syn_recv_sock()Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock()is done too late.After tcp_v4_syn_recv_sock(), the child socket is already visiblefrom TCP ehash table and other cpus might use it.Since newinet->pinet6 is still pointing to the listener ipv6_pinfobad things can happen as syzbot found.Move the problematic code in tcp_v6_mapped_child_init()and call this new helper from tcp_v4_syn_recv_sock() beforethe ehash insertion.This allows the removal of one tcp_sync_mss(), sincetcp_v4_syn_recv_sock() will call it with the correctcontext.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:atm: fore200e: fix use-after-free in tasklets during device removalWhen the PCA-200E or SBA-200E adapter is being detached, the fore200eis deallocated. However, the tx_tasklet or rx_tasklet may still be runningor pending, leading to use-after-free bug when the already freed fore200eis accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet().One of the race conditions can occur as follows:CPU 0 (cleanup) | CPU 1 (tasklet)fore200e_pca_remove_one() | fore200e_interrupt() fore200e_shutdown() | tasklet_schedule() kfree(fore200e) | fore200e_tx_tasklet() | fore200e-> // UAFFix this by ensuring tx_tasklet or rx_tasklet is properly canceled beforethe fore200e is released. Add tasklet_kill() in fore200e_shutdown() tosynchronize with any pending or running tasklets. Moreover, sincefore200e_reset() could prevent further interrupts or data transfers,the tasklet_kill() should be placed after fore200e_reset() to preventthe tasklet from being rescheduled in fore200e_interrupt(). Finally,it only needs to do tasklet_kill() when the fore200e state is greaterthan or equal to FORE200E_STATE_IRQ, since tasklets are uninitializedin earlier states. In a word, the tasklet_kill() should be placed inthe FORE200E_STATE_IRQ branch within the switch...case structure.This bug was identified through static analysis.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix locking usage for tcon fieldsWe used to use the cifs_tcp_ses_lock to protect a lot of objectsthat are not just the server, ses or tcon lists. We later introducedsrv_lock, ses_lock and tc_lock to protect fields within thecorresponding structs. This was done to provide a more granularprotection and avoid unnecessary serialization.There were still a couple of uses of cifs_tcp_ses_lock to providetcon fields. In this patch, I've replaced them with tc_lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: Fix net_device lifecycle with device_moveThe network device outlived its parent gadget device duringdisconnection, resulting in dangling sysfs links and null pointerdereference problems.A prior attempt to solve this by removing SET_NETDEV_DEV entirely [1]was reverted due to power management ordering concerns and a NO-CARRIERregression.A subsequent attempt to defer net_device allocation to bind [2] broke1:1 mapping between function instance and network device, making itimpossible for configfs to report the resolved interface name. Thisresults in a regression where the DHCP server fails on pmOS.Use device_move to reparent the net_device between the gadget device and/sys/devices/virtual/ across bind/unbind cycles. This preserves thenetwork interface across USB reconnection, allowing the DHCP server toretain their binding.Introduce gether_attach_gadget()/gether_detach_gadget() helpers and use__free(detach_gadget) macro to undo attachment on bind failure. Thebind_count ensures device_move executes only on the first bind.[1] https://lore.kernel.org/lkml/f2a4f9847617a0929d62025748384092e5f35cce.camel@crapouillou.net/[2] https://lore.kernel.org/linux-usb/795ea759-7eaf-4f78-81f4-01ffbf2d7961@ixit.cz/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix double free in rxe_srq_from_initIn rxe_srq_from_init(), the queue pointer 'q' is assigned to'srq->rq.queue' before copying the SRQ number to user space.If copy_to_user() fails, the function calls rxe_queue_cleanup()to free the queue, but leaves the now-invalid pointer in'srq->rq.queue'.The caller of rxe_srq_from_init() (rxe_create_srq) eventuallycalls rxe_srq_cleanup() upon receiving the error, which triggersa second rxe_queue_cleanup() on the same memory, leading to adouble free.The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core]Fix this by moving 'srq->rq.queue = q' after copy_to_user.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.222.1 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:serial: caif: fix use-after-free in caif_serial ldisc_close()There is a use-after-free bug in caif_serial where handle_tx() mayaccess ser->tty after the tty has been freed.The race condition occurs between ldisc_close() and packet transmission: CPU 0 (close) CPU 1 (xmit) ------------- ------------ ldisc_close() tty_kref_put(ser->tty) [tty may be freed here] <-- race window --> caif_xmit() handle_tx() tty = ser->tty // dangling ptr tty->ops->write() // UAF! schedule_work() ser_release() unregister_netdevice()The root cause is that tty_kref_put() is called in ldisc_close() whilethe network device is still active and can receive packets.Since ser and tty have a 1:1 binding relationship with consistentlifecycles (ser is allocated in ldisc_open and freed in ser_releasevia unregister_netdevice, and each ser binds exactly one tty), we cansafely defer the tty reference release to ser_release() where thenetwork device is unregistered.Fix this by moving tty_kref_put() from ldisc_close() to ser_release(),after unregister_netdevice(). This ensures the tty reference is heldas long as the network device exists, preventing the UAF.Note: We save ser->tty before unregister_netdevice() because ser isembedded in netdev's private data and will be freed along with netdev(needs_free_netdev = true).How to reproduce: Add mdelay(500) at the beginning of ldisc_close()to widen the race window, then run the reproducer program [1].Note: There is a separate deadloop issue in handle_tx() when usingPORT_UNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without properserial backend). This deadloop exists even without this patch,and is likely caused by inconsistency between uart_write_room() anduart_write() in serial core. It has been addressed in a separatepatch [2].KASAN report:==================================================================BUG: KASAN: slab-use-after-free in handle_tx+0x5d1/0x620Read of size 1 at addr ffff8881131e1490 by task caif_uaf_trigge/9929Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xd0/0x630 kasan_report+0xe4/0x120 handle_tx+0x5d1/0x620 dev_hard_start_xmit+0x9d/0x6c0 __dev_queue_xmit+0x6e2/0x4410 packet_xmit+0x243/0x360 packet_sendmsg+0x26cf/0x5500 __sys_sendto+0x4a3/0x520 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0xc9/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f615df2c0d7Allocated by task 9930:Freed by task 64:Last potentially related work creation:The buggy address belongs to the object at ffff8881131e1000 which belongs to the cache kmalloc-cg-2k of size 2048The buggy address is located 1168 bytes inside of freed 2048-byte region [ffff8881131e1000, ffff8881131e1800)The buggy address belongs to the physical page:page_owner tracks the page as allocatedpage last free pid 9778 tgid 9778 stack trace:Memory state around the buggy address: ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb>ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb==================================================================[1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb[2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: alb: fix UAF in rlb_arp_recv during bond up/downThe ALB RX path may access rx_hashtbl concurrently with bondteardown. During rapid bond up/down cycles, rlb_deinitialize()frees rx_hashtbl while RX handlers are still running, leadingto a null pointer dereference detected by KASAN.However, the root cause is that rlb_arp_recv() can still be accessedafter setting recv_probe to NULL, which is actually a use-after-free(UAF) issue. That is the reason for using the referenced commit in theFixes tag.[ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI[ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef][ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary)[ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022[ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding][ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00[ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206[ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e[ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8[ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8[ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119[ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810[ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000[ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0[ 214.310347] Call Trace:[ 214.313070] [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding][ 214.320975] bond_handle_frame+0x166/0xb60 [bonding][ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding][ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710[ 214.339199] ? __pfx_arp_process+0x10/0x10[ 214.343775] ? sched_balance_find_src_group+0x98/0x630[ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10[ 214.356513] ? arp_rcv+0x307/0x690[ 214.360311] ? __pfx_arp_rcv+0x10/0x10[ 214.364499] ? __lock_acquire+0x58c/0xbd0[ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0[ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10[ 214.380743] ? lock_acquire+0x10b/0x140[ 214.385026] process_backlog+0x3f1/0x13a0[ 214.389502] ? process_backlog+0x3aa/0x13a0[ 214.394174] __napi_poll.constprop.0+0x9f/0x370[ 214.399233] net_rx_action+0x8c1/0xe60[ 214.403423] ? __pfx_net_rx_action+0x10/0x10[ 214.408193] ? lock_acquire.part.0+0xbd/0x260[ 214.413058] ? sched_clock_cpu+0x6c/0x540[ 214.417540] ? mark_held_locks+0x40/0x70[ 214.421920] handle_softirqs+0x1fd/0x860[ 214.426302] ? __pfx_handle_softirqs+0x10/0x10[ 214.431264] ? __neigh_event_send+0x2d6/0xf50[ 214.436131] do_softirq+0xb1/0xf0[ 214.439830] The issue is reproducible by repeatedly runningip link set bond0 up/down while receiving ARP messages, whererlb_arp_recv() can race with rlb_deinitialize() and dereferencea freed rx_hashtbl entry.Fix this by setting recv_probe to NULL and then callingsynchronize_net() to wait for any concurrent RX processing to finish.This ensures that no RX handler can access rx_hashtbl after it is freedin bond_alb_deinitialize().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.222.1 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: core: Fix thermal zone governor cleanup issuesIf thermal_zone_device_register_with_trips() fails after addinga thermal governor to the thermal zone being registered, thegovernor is not removed from it as appropriate which may lead toa memory leak.In turn, thermal_zone_device_unregister() calls thermal_set_governor()without acquiring the thermal zone lock beforehand which may race witha governor update via sysfs and may lead to a use-after-free in thatcase.Address these issues by adding two thermal_set_governor() calls, one tothermal_release() to remove the governor from the given thermal zone,and one to the thermal zone registration error path to cover failurespreceding the thermal zone device registration.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.222.1 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ceph: only d_add() negative dentries when they are unhashedCeph can call d_add(dentry, NULL) on a negative dentry that is alreadypresent in the primary dcache hash.In the current VFS that is not safe. d_add() goes through __d_add()to __d_rehash(), which unconditionally reinserts dentry->d_hash intothe hlist_bl bucket. If the dentry is already hashed, reinserting thesame node can corrupt the bucket, including creating a self-loop.Once that happens, __d_lookup() can spin forever in the hlist_bl walk,typically looping only on the d_name.hash mismatch check andeventually triggering RCU stall reports like this one: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__d_lookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7eThis is reachable with reused cached negative dentries. A Ceph lookupor atomic_open can be handed a negative dentry that is already hashed,and fs/ceph/dir.c then hits one of two paths that incorrectly assume"negative" also means "unhashed": - ceph_finish_lookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL) - ceph_lookup(): local ENOENT fast path for a complete directory with shared caps -> d_add(dentry, NULL)Both paths can therefore re-add an already-hashed negative dentry.Ceph already uses the correct pattern elsewhere: ceph_fill_trace() onlycalls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn)is true.Fix both fs/ceph/dir.c sites the same way: only call d_add() for anegative dentry when it is actually unhashed. If the negative dentryis already hashed, leave it in place and reuse it as-is.This preserves the existing behavior for unhashed dentries whileavoiding d_hash list corruption for reused hashed negatives.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: fix race between ICReq handling and queue teardownnvmet_tcp_handle_icreq() updates queue->state after sending anInitialization Connection Response (ICResp), but it does so withoutserializing against target-side queue teardown.If an NVMe/TCP host sends an Initialization Connection Request(ICReq) and immediately closes the connection, target-side teardownmay start in softirq context before io_work drains the alreadybuffered ICReq. In that case, nvmet_tcp_schedule_release_queue()sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queuereference under state_lock.If io_work later processes that ICReq, nvmet_tcp_handle_icreq() canstill overwrite the state back to NVMET_TCP_Q_LIVE. That defeats theDISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() andallows a later socket state change to re-enter teardown and issue asecond kref_put() on an already released queue.The ICResp send failure path has the same problem. If teardown hasalready moved the queue to DISCONNECTING, a send error can stilloverwrite the state with NVMET_TCP_Q_FAILED, again reopening thewindow for a second teardown path to drop the queue reference.Fix this by serializing both post-send state transitions withstate_lock and bailing out if teardown has already started.Use -ESHUTDOWN as an internal sentinel for that bail-out path ratherthan propagating it as a transport error like -ECONNRESET. Keepnvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR beforehonoring that sentinel so receive-side parsing stays quiesced until theexisting release path completes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mana: Validate rx_hash_key_lenSashiko points out that rx_hash_key_len comes from a uAPI structure and isblindly passed to memcpy, allowing the userspace to trash kernelmemory. Bounds check it so the memcpy cannot overflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:exit: prevent preemption of oopsing TASK_DEAD taskWhen an already-exiting task oopses, make_task_dead() currently callsdo_task_dead() with preemption enabled. That is forbidden:do_task_dead() calls __schedule(), which has a comment saying "WARNING:must be called with preemption disabled!".If an oopsing task is preempted in do_task_dead(), between becomingTASK_DEAD and entering the scheduler explicitly, bad things happen:finish_task_switch() assumes that once the scheduler has switched awayfrom a TASK_DEAD task, the task can never run again and its stack is nolonger needed; but that assumption apparently doesn't hold if the deadtask was preempted (the SM_PREEMPT case).This means that the scheduler ends up repeatedly dropping references onthe dead task's stack, which can lead to use-after-free or double-freeof the entire task stack; in other words, two tasks can end up runningon the same stack, resulting in various kinds of memory corruption.(This does not just affect "recursively oopsing" tasks; it is enough tooops once during task exit, for example in a file_operations::releasehandler)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs()drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensionsusing plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1);However, the ioctl-level framebuffer_check() in drm_framebuffer.c usesdrm_format_info_plane_width/height() which round up dimensions viaDIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM objectsize check for certain pixel format and dimension combinations.For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer theGEM size validation path sees height=0 instead of height=1. Theexpression (height - 1) then wraps to UINT_MAX as an unsigned int,causing min_size to overflow and wrap back to a small value. A tinyGEM object therefore passes the size guard, yet when the GPU accessesthe chroma plane it will read or write memory beyond the object'sbounds.Fix by replacing the open-coded divisions with drm_format_info_plane_width()and drm_format_info_plane_height(), which use DIV_ROUND_UP() and matchthe calculation already used in framebuffer_check().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALLThe SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs withlist_for_each_entry_safe(), which caches the next entry in @tmp beforethe loop body runs. The body calls sctp_sendmsg_to_asoc(), which maydrop the socket lock inside sctp_wait_for_sndbuf().While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF theassociation cached in @tmp, migrating it to a new endpoint viasctp_sock_migrate() (list_del_init() + list_add_tail() tonewep->asocs), and optionally close the new socket which frees theassociation via kfree_rcu(). The cached @tmp can also be freed by anetwork ABORT for that association, processed in softirq while thelock is dropped.sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lockvia the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothingrevalidates @tmp. After a successful return, the iterator advances tothe stale @tmp, yielding either a use-after-free (if the peeled socketwas closed) or a list-walk onto the new endpoint's list head (typeconfusion of &newep->asocs as a struct sctp_association *).Both are reachable from CapEff=0; the type-confusion path givescontrolled indirect call via the outqueue.sched->init_sid pointer.Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc()returns. @asoc is known to still be on ep->asocs at that point: theonly callers that list_del an association from ep->asocs aresctp_association_free() (which sets asoc->base.dead) andsctp_assoc_migrate() (which changes asoc->base.sk), andsctp_wait_for_sndbuf() checks both under the lock before anysuccessful return; a tripped check propagates as err < 0 and the loopbails before the re-derive.The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and theloop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, sothe @tmp cached by list_for_each_entry_safe() still covers thelock-held free that ba59fb027307 ("sctp: walk the list of asocsafely") was added for.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMPYizhou Zhao reported that simply having one RAW socket on protocolIPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255);A malicious incoming ICMP packet can set the protocol field to 255and match this socket, leading to FNHE cache changes.inner = IP(src="192.168.2.1", dst="8.8.8.8", proto=255)/Raw("TEST")pkt = IP(src="192.168.1.1", dst="192.168.2.1")/ICMP(type=3, code=4, nexthopmtu=576)/inner"man 7 raw" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets.Make sure we drop these malicious packets.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: purge outqueue on stale COOKIE-ECHO handlingsctp_stream_update() is only invoked when the association is moved intoCOOKIE_WAIT during association setup/reconfiguration. In this path, theoutbound stream scheduler state (stream->out_curr) is expected to beclean, since no user data should have been transmitted yet unless thestate machine has already partially progressed.However, a corner case exists in sctp_sf_do_5_2_6_stale(): when aStale Cookie ERROR is received, the association is rolled back fromCOOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may alreadyhave been queued and even bundled with the COOKIE-ECHO chunk.During the rollback, sctp_stream_update() frees the old stream tableand installs a new one, but it does not invalidate stream->out_curr.As a result, out_curr may still point to a freed sctp_stream_outentry from the previous stream state.Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely onstream->out_curr->ext, which can lead to use-after-free once the oldstream state has been released via sctp_stream_free().This results in crashes such as (reported by Yuqi): BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctp_sched_fcfs_dequeue+0x13a/0x140 sctp_outq_flush+0x1603/0x33e0 sctp_do_sm+0x31c9/0x5d30 sctp_assoc_bh_rcv+0x392/0x6f0 sctp_inq_push+0x1db/0x270 sctp_rcv+0x138d/0x3c10Fix this by fully purging the association outqueue when handling theStale Cookie case. This ensures all pending transmit and retransmitstate is dropped, and any scheduler cached pointers are invalidated,making it safe to rebuild stream state during COOKIE_WAIT restart.Updating only stream->out_curr would be insufficient, since queuedand retransmittable data would still reference the old stream state andtrigger later use-after-free in dequeue paths.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: skbuff: fix missing zerocopy reference in pskb_carve helperspskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copythe old skb_shared_info header into a new buffer via memcpy(), whichincludes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs.Neither function calls net_zcopy_get() for the new shinfo, creating anunaccounted holder: every skb_shared_info with destructor_arg set willcall skb_zcopy_clear() once when freed, but the correspondingnet_zcopy_get() was never called for the new copy. Repeated callsdrive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc whileTX skbs still hold live destructor_arg pointers.KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530The skb consuming the late access still referenced the same uarg viashinfo->destructor_arg copied by pskb_carve_inside_nonlinear() withouta refcount bump. This has been verified to be reliably exploitable: aworking proof-of-concept achieves full root privilege escalation froman unprivileged local user on a default kernel configuration.The fix follows the pattern of pskb_expand_head() which has the samememcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get()is placed after skb_orphan_frags() succeeds, so the orphan error pathneeds no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() isplaced after all failure points and just before skb_release_data(), sono error path needs cleanup at all -- matching pskb_expand_head() moreclosely and avoiding the need for a balancing net_zcopy_put().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:quota: Fix race of dquot_scan_active() with quota deactivationdquot_scan_active() can race with quota deactivation inquota_release_workfn() like: CPU0 (quota_release_workfn) CPU1 (dquot_scan_active) ============================== ============================== spin_lock(&dq_list_lock); list_replace_init( &releasing_dquots, &rls_head); /* dquot X on rls_head, dq_count == 0, DQ_ACTIVE_B still set */ spin_unlock(&dq_list_lock); synchronize_srcu(&dquot_srcu); spin_lock(&dq_list_lock); list_for_each_entry(dquot, &inuse_list, dq_inuse) { /* finds dquot X */ dquot_active(X) -> true atomic_inc(&X->dq_count); } spin_unlock(&dq_list_lock); spin_lock(&dq_list_lock); dquot = list_first_entry(&rls_head); WARN_ON_ONCE(atomic_read(&dquot->dq_count));The problem is not only a cosmetic one as under memory pressure thecaller of dquot_scan_active() can end up working on freed dquot.Fix the problem by making sure the dquot is removed from releasing listwhen we acquire a reference to it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Fix clone_alias() to use the original device's devidCurrently clone_alias() assumes first argument (pdev) is always theoriginal device pointer. This function is called bypci_for_each_dma_alias() which based on topology decides to sendoriginal or alias device details in first argument.This meant that the source devid used to look up and copy the DTEmay be incorrect, leading to wrong or stale DTE entries beingpropagated to alias device.Fix this by passing the original pdev as the opaque data argument toboth the direct clone_alias() call and pci_for_each_dma_alias(). Insideclone_alias(), retrieve the original device from data and compute devidfrom it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: Vim is an open source, command line text editor. From 9.1.1784 until 9.2.0678, when the bundled zip plugin autoload/zip.vim falls back to PowerShell to browse, read, extract, update or delete entries in a zip archive, it builds the PowerShell command by inserting archive entry names that are quoted only for the shell, not for PowerShell. A crafted entry name can break out of the intended string context and cause PowerShell to execute arbitrary commands with the privileges of the user running Vim, triggered by opening, viewing or extracting the archive. This vulnerability is fixed in 9.2.0678.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.2.0280-150000.5.89.1).

CVE-2026-56132 Severity: Moderate CVSS3 score: 6.9

Description: In libexpat before 2.8.2, there is a heap-based buffer overflow in doProlog in xmlparse.c because scaffold backing array reallocation is mishandled when there is data-structure sharing across parsers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.37.1).

CVE-2026-56403 Severity: Moderate CVSS3 score: 6.9

Description: libexpat before 2.8.2 has an integer overflow in storeAtts.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

CVE-2026-56404 Severity: Moderate CVSS3 score: 6.9

Description: libexpat before 2.8.2 has an integer overflow in addBinding.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

CVE-2026-56405 Severity: Moderate CVSS3 score: 6.9

Description: libexpat before 2.8.2 has an integer overflow in getAttributeId.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

CVE-2026-56406 Severity: Moderate CVSS3 score: 6.9

Description: libexpat before 2.8.2 has an integer overflow in XML_ParseBuffer because it lacked a check that was present in XML_Parse.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

CVE-2026-56407 Severity: Moderate CVSS3 score: 6.9

Description: libexpat before 2.8.2 has an integer overflow in doProlog that is related to storeEntityValue and entity textLen.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

CVE-2026-56408 Severity: Moderate CVSS3 score: 6.9

Description: libexpat before 2.8.2 has an integer overflow in copyString.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

CVE-2026-56411 Severity: Moderate CVSS3 score: 6.9

Description: xmlwf in libexpat before 2.8.2 has an integer overflow in endDoctypeDecl via NOTATION declarations.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

CVE-2026-5958 Severity: Moderate CVSS3 score: 6.9

Description: When sed is invoked with both -i (in-place edit) and --follow-symlinks, the function open_next_file() performs two separate, non-atomic filesystem operations on the same path: 1. resolves symlink to its target and stores the resolved path for determining when output is written,2. opens the original symlink path (not the resolved one) to read the file. Between these two calls there is a race window. If an attacker atomically replaces the symlink with a different target during that window, sed will: read content from the new (attacker-chosen) symlink target and write the processed result to the path recorded in step 1. This can lead to arbitrary file overwrite with attacker-controlled content in the context of the sed process.This issue was fixed in version 4.10.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
sed > 0-0 (version in image is 4.4-150300.13.6.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

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

Description: jq is a command-line JSON processor. An integer overflow vulnerability exists through version 1.8.1 within the jvp_string_append() and jvp_string_copy_replace_bad functions, where concatenating strings with a combined length exceeding 2^31 bytes causes a 32-bit unsigned integer overflow in the buffer allocation size calculation, resulting in a drastically undersized heap buffer. Subsequent memory copy operations then write the full string data into this undersized buffer, causing a heap buffer overflow classified as CWE-190 (Integer Overflow) leading to CWE-122 (Heap-based Buffer Overflow). Any system evaluating untrusted jq queries is affected, as an attacker can crash the process or potentially achieve further exploitation through heap corruption by crafting queries that produce extremely large strings. The root cause is the absence of string size bounds checking, unlike arrays and objects which already have size limits. The issue has been addressed in commit e47e56d226519635768e6aab2f38f0ab037c09e5.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
jq > 0-0 (version in image is 1.6-150000.3.12.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: Fix slab-out-of-bounds access in auth message processingIf a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLYcontains a positive value in its result field, it is treated as anerror code by ceph_handle_auth_reply() and returned tohandle_auth_reply(). Thereafter, an attempt is made to send thepreallocated message of type CEPH_MSG_AUTH, where the returned value isinterpreted as the size of the front segment to send. If the resultvalue in the message is greater than the size of the memory bufferallocated for the front segment, an out-of-bounds access occurs, andthe content of the memory region beyond this buffer is sent out.This patch fixes the issue by treating only negative values in theresult field as errors. Positive values are therefore treated as successin the same way as a zero value. Additionally, a BUG_ON is added to__send_prepared_auth_request() comparing the len parameter tofront_alloc_len to prevent sending the message if it exceeds the boundsof the allocation and to make it easier to catch any logic flaws leadingto this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size[Why & How]During HDCP 2.x repeater authentication over HDMI, the driver reads thesink's RxStatus register and extracts a 10-bit message size field (maxvalue 1023). This value is used as the read length for the ReceiverIDlist without being clamped to the size of the destination bufferrx_id_list[177]. A malicious HDMI repeater could advertise a messagesize larger than the buffer, causing an out-of-bounds write during theI2C read.Clamp the read length in mod_hdcp_read_rx_id_list() to the size of therx_id_list buffer, matching the approach already used in the DP branch.(cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: make ebt_snat ARP rewrite writableThe ebtables SNAT target keeps the Ethernet source address rewritebehind skb_ensure_writable(skb, 0). This is intentional: at the bridgeebtables hooks the Ethernet header is addressed throughskb_mac_header()/eth_hdr(), while skb->data points at the Ethernetpayload. Asking skb_ensure_writable() for ETH_HLEN bytes would checkthe payload, not the Ethernet header, and would reintroduce the smallpacket regression fixed by commit 63137bc5882a.However, the optional ARP sender hardware address rewrite is different.It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN)skb_header_pointer() only safely reads the ARP header; it does not makethe later sender hardware address range writable. If that range isstill held in a nonlinear skb fragment backed by a splice-imported filepage, skb_store_bits() maps the frag page and copies the new MAC addressdirectly into it.Ensure the ARP SHA range is writable before reading the ARP header andbefore calling skb_store_bits().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: urllib3 version 2.6.3 is vulnerable to a decompression bomb bypass in its streaming API (`preload_content=False`) when using Brotli support. The issue arises due to three independent code paths in `response.py` that bypass the `max_length` protection introduced in version 2.6.0 to mitigate CVE-2025-66471. Specifically, negative `max_length` values can be produced due to buffer arithmetic in `read()`, `flush_decoder` unconditionally overrides `max_length` to `-1`, and `_flush_decoder()` passes no limit at all, defaulting to unlimited decompression. This allows a malicious HTTP server to trigger an out-of-memory (OOM) condition by decompressing large payloads into memory, leading to a denial of service (DoS). The vulnerability affects urllib3 2.6.3 and Brotli 1.2.0 and impacts applications and libraries using `requests` or `urllib3` to stream content from untrusted sources.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311-urllib3 > 0-0 (version in image is 2.0.7-150400.7.27.1).

CVE-2013-4235 Severity: Moderate CVSS3 score: 6.7

Description: shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
login_defs > 0-0 (version in image is 4.8.1-150400.10.24.1).

CVE-2022-48733 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix use-after-free after failure to create a snapshotAt ioctl.c:create_snapshot(), we allocate a pending snapshot structure andthen attach it to the transaction's list of pending snapshots. After thatwe call btrfs_commit_transaction(), and if that returns an error we jumpto 'fail' label, where we kfree() the pending snapshot structure. This canresult in a later use-after-free of the pending snapshot:1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots;2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list;3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free.This issue could actually be detected by smatch, which produced thefollowing warning: fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from listSo fix this by not having the snapshot creation ioctl directly add thepending snapshot to the transaction's list. Instead add the pendingsnapshot to the transaction handle, and then at btrfs_commit_transaction()we add the snapshot to the list only when we can guarantee that any errorreturned after that point will result in a transaction abort, in whichcase the ioctl code can safely free the pending snapshot and no one canaccess it anymore.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49961 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZEROPrecision markers need to be propagated whenever we have an ARG_CONST_*style argument, as the verifier cannot consider imprecise scalars to beequivalent for the purposes of states_equal check when such argumentsrefine the return value (in this case, set mem_size for PTR_TO_MEM). Theresultant mem_size for the R0 is derived from the constant value, and ifthe verifier incorrectly prunes states considering them equivalent wheresuch arguments exist (by seeing that both registers have reg->precise asfalse in regsafe), we can end up with invalid programs passing theverifier which can do access beyond what should have been the correctmem_size in that explored state.To show a concrete example of the problem:0000000000000000 : 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 10: r2 = -10000000000000058 : 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit00000000000000b8 : 23: w0 = 0 24: exitFor the first case, the single line execution's exploration will prunethe search at insn 14 for the branch insn 9's second leg as it will beverified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 willalways be 0 so at runtime we don't get error for being greater thanUINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe justsees reg->precise as false for both r2 registers in both states, henceconsiders them equal for purposes of states_equal.If we propagated precise markers using the backtracking support, wewould use the precise marking to then ensure that old r2 (UINT_MAX) waswithin the new r2 (1) and this would never be true, so the verificationwould rightfully fail.The end result is that the out of bounds access at instruction 19 wouldbe permitted without this fix.Note that reg->precise is always set to true when user does not haveCAP_BPF (or when subprog count is greater than 1 (i.e. use of any staticor global functions)), hence this is only a problem when precision marksneed to be explicitly propagated (i.e. privileged users with CAP_BPF).A simplified test case has been included in the next patch to preventfuture regressions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50746 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: validate the extent length for uncompressed pclusterssyzkaller reported a KASAN use-after-free:https://syzkaller.appspot.com/bug?extid=2ae90e873e97f1faf6f2The referenced fuzzed image actually has two issues: - m_pa == 0 as a non-inlined pcluster; - The logical length is longer than its physical length.The first issue has already been addressed. This patch addressesthe second issue by checking the extent length validity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52620 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: disallow timeout for anonymous setsNever used from userspace, disallow these parameters.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53338 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:lwt: Fix return values of BPF xmit opsBPF encap ops can return different types of positive values, such likeNET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from functionskb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such returnvalues would be treated implicitly as LWTUNNEL_XMIT_CONTINUE inip(6)_finish_output2. When this happens, skbs that have been freed wouldcontinue to the neighbor subsystem, causing use-after-free bug andkernel crashes.To fix the incorrect behavior, skb_do_redirect return values can besimply discarded, the same as tc-egress behavior. On the other hand,bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTUinformation. Thus convert its return values to avoid the conflict withLWTUNNEL_XMIT_CONTINUE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-6817 Severity: Moderate CVSS3 score: 6.7

Description: A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.The function nft_pipapo_walk did not skip inactive elements during set walk which could lead double deactivations of PIPAPO (Pile Packet Policies) elements, leading to use-after-free.We recommend upgrading past commit 317eb9685095678f2c9f5a8189de698c5354316a.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_triggerWhen the cpu5wdt module is removing, the origin code uses del_timer() tode-activate the timer. If the timer handler is running, del_timer() couldnot stop it and will return directly. If the port region is released byrelease_region() and then the timer handler cpu5wdt_trigger() calls outb()to write into the region that is released, the use-after-free bug willhappen.Change del_timer() to timer_shutdown_sync() in order that the timer handlercould be finished before the port region is released.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:VMCI: Fix use-after-free when removing resource in vmci_resource_remove()When removing a resource from vmci_resource_table invmci_resource_remove(), the search is performed using the resourcehandle by comparing context and resource fields.It is possible though to create two resources with different typesbut same handle (same context and resource fields).When trying to remove one of the resources, vmci_resource_remove()may not remove the intended one, but the object will still be freedas in the case of the datagram type in vmci_datagram_destroy_handle().vmci_resource_table will still hold a pointer to this freed resourceleading to a use-after-free vulnerability.BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425 kasan_report+0x38/0x51 mm/kasan/report.c:442 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444 kref_put include/linux/kref.h:65 [inline] vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline] vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143 __fput+0x261/0xa34 fs/file_table.c:282 task_work_run+0xf0/0x194 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline] syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x6e/0x0This change ensures the type is also checked when removingthe resource from vmci_resource_table in vmci_resource_remove().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix helper writes to read-only mapsLonial found an issue that despite user- and BPF-side frozen BPF map(like in case of .rodata), it was still possible to write into it froma BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT}as arguments.In check_func_arg() when the argument is as mentioned, the meta->raw_modeis never set. Later, check_helper_mem_access(), under the case ofPTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for thesubsequent call to check_map_access_type() and given the BPF map isread-only it succeeds.The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINITwhen results are written into them as opposed to read out of them. Thelatter indicates that it's okay to pass a pointer to uninitialized memoryas the memory is written to anyway.However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEMjust with additional alignment requirement. So it is better to just getrid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse thefixed size memory types. For this, add MEM_ALIGNED to additionally ensurealignment given these helpers write directly into the args via * = val.The .arg*_size has been initialized reflecting the actual sizeof(*).MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotatedargument types, since in !MEM_FIXED_SIZE cases the verifier does not knowthe buffer size a priori and therefore cannot blindly write * = val.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix usage slab after free[ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147[ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1[ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020[ +0.000016] Call Trace:[ +0.000008] [ +0.000009] dump_stack_lvl+0x76/0xa0[ +0.000017] print_report+0xce/0x5f0[ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000019] ? srso_return_thunk+0x5/0x5f[ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200[ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000019] kasan_report+0xbe/0x110[ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000023] __asan_report_load8_noabort+0x14/0x30[ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000020] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? __kasan_check_write+0x14/0x30[ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched][ +0.000020] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? __kasan_check_write+0x14/0x30[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? enable_work+0x124/0x220[ +0.000015] ? __pfx_enable_work+0x10/0x10[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? free_large_kmalloc+0x85/0xf0[ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched][ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu][ +0.000735] ? __kasan_check_read+0x11/0x20[ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu][ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu][ +0.000679] ? mutex_unlock+0x80/0xe0[ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu][ +0.000662] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? __kasan_check_write+0x14/0x30[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? mutex_unlock+0x80/0xe0[ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu][ +0.000663] drm_minor_release+0xc9/0x140 [drm][ +0.000081] drm_release+0x1fd/0x390 [drm][ +0.000082] __fput+0x36c/0xad0[ +0.000018] __fput_sync+0x3c/0x50[ +0.000014] __x64_sys_close+0x7d/0xe0[ +0.000014] x64_sys_call+0x1bc6/0x2680[ +0.000014] do_syscall_64+0x70/0x130[ +0.000014] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190[ +0.000015] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? irqentry_exit+0x43/0x50[ +0.000012] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? exc_page_fault+0x7c/0x110[ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ +0.000014] RIP: 0033:0x7ffff7b14f67[ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff[ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003[ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67[ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003[ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000[ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8[ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040[ +0.000020] [ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:[ +0.000014] kasan_save_stack+0x28/0x60[ +0.000008] kasan_save_track+0x18/0x70[ +0.000007] kasan_save_alloc_info+0x38/0x60[ +0.000007] __kasan_kmalloc+0xc1/0xd0[ +0.000007] kmalloc_trace_noprof+0x180/0x380[ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched][ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu][ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu][ +0.000662] amdgpu_pci_p---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/igen6: Avoid segmentation fault on module unloadThe segmentation fault happens because:During modprobe:1. In igen6_probe(), igen6_pvt will be allocated with kzalloc()2. In igen6_register_mci(), mci->pvt_info will point to &igen6_pvt->imc[mc]During rmmod:1. In mci_release() in edac_mc.c, it will kfree(mci->pvt_info)2. In igen6_remove(), it will kfree(igen6_pvt);Fix this issue by setting mci->pvt_info to NULL to avoid the doublekfree.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Remove the direct link to net_deviceThe similar patch in siw is in the link:https://git.kernel.org/rdma/rdma/c/16b87037b48889This problem also occurred in RXE. The following analyze this problem.In the following Call Traces:"BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 net/core/dev.c:8782Read of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295CPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0Hardware name: Google Compute Engine/Google Compute Engine,BIOS Google 09/13/2024Workqueue: infiniband ib_cache_event_taskCall 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 dev_get_flags+0x188/0x1d0 net/core/dev.c:8782 rxe_query_port+0x12d/0x260 drivers/infiniband/sw/rxe/rxe_verbs.c:60 __ib_query_port drivers/infiniband/core/device.c:2111 [inline] ib_query_port+0x168/0x7d0 drivers/infiniband/core/device.c:2143 ib_cache_update+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494 ib_cache_event_task+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 "1). In the link [1]," infiniband syz2: set down"This means that on 839.350575, the event ib_cache_event_task was sent andiqueued in ib_wq.2). In the link [1]," team0 (unregistering): Port device team_slave_0 removed"It indicates that before 843.251853, the net device should be freed.3). In the link [1]," BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0"This means that on 850.559070, this slab-use-after-free problem occurred.In all, on 839.350575, the event ib_cache_event_task was sent and queuedin ib_wq,before 843.251853, the net device veth was freed.on 850.559070, this event was executed, and the mentioned freed net devicewas called. Thus, the above call trace occurred.[1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Remove direct link to net_deviceDo not manage a per device direct link to net_device. Relyon associated ib_devices net_device management, not doublingthe effort locally. A badly managed local link to net_devicewas causing a 'KASAN: slab-use-after-free' exception duringsiw_query_port() call.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:dm array: fix releasing a faulty array block twice in dm_array_cursor_endWhen dm_bm_read_lock() fails due to locking or checksum errors, itreleases the faulty block implicitly while leaving an invalid outputpointer behind. The caller of dm_bm_read_lock() should not operate onthis invalid dm_block pointer, or it will lead to undefined result.For example, the dm_array_cursor incorrectly caches the invalid pointeron reading a faulty array block, causing a double release indm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().Reproduce steps:1. initialize a cache devicedmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc $262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"2. wipe the second array block offlinedmsteup remove cache cmeta cdata corigmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \2>/dev/null | hexdump -e '1/8 "%u\n"')ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \2>/dev/null | hexdump -e '1/8 "%u\n"')dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try reopen the cache devicedmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc $262144"dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"Kernel logs:(snip)device-mapper: array: array_block_check failed: blocknr 0 != wanted 10device-mapper: block manager: array validator check failed for block 10device-mapper: array: get_ablock faileddevice-mapper: cache metadata: dm_array_cursor_next for mapping failed------------[ cut here ]------------kernel BUG at drivers/md/dm-bufio.c:638!Fix by setting the cached block pointer to NULL on errors.In addition to the reproducer described above, this fix can beverified using the "array_cursor/damaged" test in dm-unit: dm-unit run /pdata/array_cursor/damaged --kernel-dir

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Fix use-after free in init error and remove pathsdevm_blk_crypto_profile_init() registers a cleanup handler to run whenthe associated (platform-) device is being released. For UFS, thecrypto private data and pointers are stored as part of the ufs_hba'sdata structure 'struct ufs_hba::crypto_profile'. This structure isallocated as part of the underlying ufshcd and therefore Scsi_hostallocation.During driver release or during error handling in ufshcd_pltfrm_init(),this structure is released as part of ufshcd_dealloc_host() before the(platform-) device associated with the crypto call above is released.Once this device is released, the crypto cleanup code will run, usingthe just-released 'struct ufs_hba::crypto_profile'. This causes ause-after-free situation: Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0In other words, the initialisation code flow is: platform-device probe ufshcd_pltfrm_init() ufshcd_alloc_host() scsi_host_alloc() allocation of struct ufs_hba creation of scsi-host devices devm_blk_crypto_profile_init() devm registration of cleanup handler using platform-deviceand during error handling of ufshcd_pltfrm_init() or during driverremoval: ufshcd_dealloc_host() scsi_host_put() put_device(scsi-host) release of struct ufs_hba put_device(platform-device) crypto cleanup handlerTo fix this use-after free, change ufshcd_alloc_host() to register adevres action to automatically cleanup the underlying SCSI device onufshcd destruction, without requiring explicit calls toufshcd_dealloc_host(). This way: * the crypto profile and all other ufs_hba-owned resources are destroyed before SCSI (as they've been registered after) * a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as it's not needed anymore * no future drivers using ufshcd_alloc_host() could ever forget adding the cleanup

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: pktgen: fix access outside of user given buffer in pktgen_thread_write()Honour the user given buffer size for the strn_len() calls (otherwisestrn_len() will access memory outside of the user given buffer).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix UAF when lookup kallsym after ftrace disabledThe following issue happens with a buggy module:BUG: unable to handle page fault for address: ffffffffc05d0218PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0Oops: Oops: 0000 [#1] SMP KASAN PTITainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSRIP: 0010:sized_strscpy+0x81/0x2f0RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2dRBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeffFS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ftrace_mod_get_kallsym+0x1ac/0x590 update_iter_mod+0x239/0x5b0 s_next+0x5b/0xa0 seq_read_iter+0x8c9/0x1070 seq_read+0x249/0x3b0 proc_reg_read+0x1b0/0x280 vfs_read+0x17f/0x920 ksys_read+0xf3/0x1c0 do_syscall_64+0x5f/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe above issue may happen as follows:(1) Add kprobe tracepoint;(2) insmod test.ko;(3) Module triggers ftrace disabled;(4) rmmod test.ko;(5) cat /proc/kallsyms; --> Will trigger UAF as test.ko already removed;ftrace_mod_get_kallsym()...strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN);...The problem is when a module triggers an issue with ftrace andsets ftrace_disable. The ftrace_disable is set when an anomaly isdiscovered and to prevent any more damage, ftrace stops all textmodification. The issue that happened was that the ftrace_disable stopsmore than just the text modification.When a module is loaded, its init functions can also be traced. Becausekallsyms deletes the init functions after a module has loaded, ftracesaves them when the module is loaded and function tracing is enabled. Thisallows the output of the function trace to show the init function namesinstead of just their raw memory addresses.When a module is removed, ftrace_release_mod() is called, and ifftrace_disable is set, it just returns without doing anything more. Theproblem here is that it leaves the mod_list still around and if kallsymsis called, it will call into this code and access the module memory thathas already been freed as it will return: strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN);Where the "mod" no longer exists and triggers a UAF bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:dm-stripe: fix a possible integer overflowThere's a possible integer overflow in stripe_io_hints if we have toolarge chunk size. Test if the overflow happened, and if it did, don't setlimits->io_min and limits->io_opt;

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/rsrc: don't rely on user vaddr alignmentThere is no guaranteed alignment for user pointers, however thecalculation of an offset of the first page into a folio after coalescinguses some weird bit mask logic, get rid of it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-22980 Severity: Moderate CVSS3 score: 6.7

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31580 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:bcache: fix cached_dev.sb_bio use-after-free and crashIn our production environment, we have received multiple crash reportsregarding libceph, which have caught our attention:```[6888366.280350] Call Trace:[6888366.280452] blk_update_request+0x14e/0x370[6888366.280561] blk_mq_end_request+0x1a/0x130[6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd][6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd][6888366.280903] __complete_request+0x22/0x70 [libceph][6888366.281032] osd_dispatch+0x15e/0xb40 [libceph][6888366.281164] ? inet_recvmsg+0x5b/0xd0[6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph][6888366.281405] ceph_con_process_message+0x79/0x140 [libceph][6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph][6888366.281661] ceph_con_workfn+0x329/0x680 [libceph]```After analyzing the coredump file, we found that the address ofdc->sb_bio has been freed. We know that cached_dev is only freed when itis stopped.Since sb_bio is a part of struct cached_dev, rather than an alloc everytime. If the device is stopped while writing to the superblock, thereleased address will be accessed at endio.This patch hopes to wait for sb_write to complete in cached_dev_free.It should be noted that we analyzed the cause of the problem, then tellall details to the QWEN and adopted the modifications it made.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31597 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRYfilemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY,as documented in mm/filemap.c: "If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap()."When this happens, a concurrent munmap() can call remove_vma() and freethe vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() thenbecomes a dangling pointer, and the subsequent trace_ocfs2_fault() calldereferences it -- a use-after-free.Fix this by saving ip_blkno as a plain integer before callingfilemap_fault(), and removing vma from the trace event. Sinceip_blkno is copied by value before the lock can be dropped, itremains valid regardless of what happens to the vma or inodeafterward.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31627 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: s3c24xx: check the size of the SMBUS message before using itThe first byte of an i2c SMBUS message is the size, and it should beverified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAXbefore processing it.This is the same logic that was added in commit a6e04f05ce0b ("i2c:tegra: check msg length in SMBUS block read") to the i2c tegra driver.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31679 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: validate MPLS set/set_masked payload lengthvalidate_set() accepted OVS_KEY_ATTR_MPLS as variable-sized payload forSET/SET_MASKED actions. In action handling, OVS expects fixed-sizeMPLS key data (struct ovs_key_mpls).Use the already normalized key_len (masked case included) and rejectnon-matching MPLS action key sizes.Reject invalid MPLS action payload lengths early.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31686 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:mm/kasan: fix double free for kasan pXdskasan_free_pxd() assumes the page table is always struct page aligned. But that's not always the case for all architectures. E.g. In case ofpowerpc with 64K pagesize, PUD table (of size 4096) comes from slab cachenamed pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's justdirectly pass the start of the pxd table which is passed as the 1stargument.This fixes the below double free kasan issue seen with PMEM:radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages==================================================================BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20Free of addr c0000003c38e0000 by task ndctl/2164CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARYHardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeriesCall Trace: dump_stack_lvl+0x88/0xc4 (unreliable) print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140 kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec---- interrupt: 3000 at 0x7fff93b3d3f4NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392)MSR: 800000000280f033 CR: 48888208 XER: 00000000<...>NIP [00007fff93b3d3f4] 0x7fff93b3d3f4LR [00007fff93b3d3f4] 0x7fff93b3d3f4---- interrupt: 3000 The buggy address belongs to the object at c0000003c38e0000 which belongs to the cache pgtable-2^9 of size 4096 The buggy address is located 0 bytes inside of 4096-byte region [c0000003c38e0000, c0000003c38e1000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:c0000003bfd63e01 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) page_type: f5(slab) raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected[ 138.953636] [ T2164] Memory state around the buggy address:[ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953669] [ T2164] ^[ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 138.953692] [ T2164] ==================================================================[ 138.953701] [ T2164] Disabling lock debugging due to kernel taint

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43076 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: validate inline data i_size during inode readWhen reading an inode from disk, ocfs2_validate_inode_block() performsvarious sanity checks but does not validate the size of inline data. Ifthe filesystem is corrupted, an inode's i_size can exceed the actualinline data capacity (id_count).This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline databuffer, triggering a use-after-free when accessing directory entries fromfreed memory.In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry()Fix by adding a validation check in ocfs2_validate_inode_block() to ensureinodes with inline data have i_size <= id_count. This catches thecorruption early during inode read and prevents all downstream code fromoperating on invalid data.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45956 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl()vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev toobtain a struct vidi_context pointer. However, drm_dev->dev is theexynos-drm master device, and the driver_data contained therein is notthe vidi component device, but a completely different device.This can lead to various bugs, ranging from null pointer dereferences andgarbage value accesses to, in unlucky cases, out-of-bounds errors,use-after-free errors, and more.To resolve this issue, we need to store/delete the vidi device pointer inexynos_drm_private->vidi_dev during bind/unbind, and then read thisexynos_drm_private->vidi_dev within ioctl() to obtain the correctstruct vidi_context pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53090 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix ld_{abs,ind} failure path analysis in subprogsUsage of ld_{abs,ind} instructions got extended into subprogs some timeago via commit 09b28d76eac4 ("bpf: Add abnormal return checks."). Theseare only allowed in subprograms when the latter are BTF annotated andhave scalar return types.The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 +exit) from legacy cBPF times. While the enforcement is on scalar returntypes, the verifier must also simulate the path of abnormal exit if thepacket data load via ld_{abs,ind} failed.This is currently not the case. Fix it by having the verifier simulateboth success and failure paths, and extend it in similar ways as we dofor tail calls. The success path (r0=unknown, continue to next insn) ispushed onto stack for later validation and the r0=0 and return to thecaller is done on the fall-through side.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53136 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Clamp VBIOS HDMI retimer register count to array size[Why & How]The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum andHdmi6GRegNum fields that are used as loop bounds when copying retimer I2Cregister settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9]and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validatedbefore use, so a malformed VBIOS can specify values up to 255, causing anout-of-bounds heap write during driver probe.Clamp each register count to the destination array size using min_t()before the copy loops, in both get_integrated_info_v11() andget_integrated_info_v2_1().(cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53216 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: mvpp2: limit XDP frame size to the RX buffermvpp2 has short and long BM pools, and short pool buffers can be smallerthan PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff withPAGE_SIZE as frame size.XDP helpers use frame_sz to validate tail growth and to derive the hardend of the data area. Advertising PAGE_SIZE for short buffers can letbpf_xdp_adjust_tail() grow a packet past the real allocation, corruptingmemory or later tripping skb tailroom checks.Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matchesthe actual buffer backing the packet.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2021-47548 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()The if statement: if (port >= DSAF_GE_NUM) return;limits the value of port less than DSAF_GE_NUM (i.e., 8).However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6).To fix this possible array overflow, we first check port and if it isgreater than or equal to DSAF_MAX_PORT_NUM, the function returns.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49727 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix signed integer overflow in l2tp_ip6_sendmsgWhen len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will beoverflow. To fix, we can follow what udpv6 does and subtract thetranshdrlen from the max.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49728 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix signed integer overflow in __ip6_append_dataResurrect ubsan overflow checks and ubsan report this warning,fix it by change the variable [length] type to size_t.UBSAN: signed-integer-overflow in net/ipv6/ip6_output.c:1489:192147479552 + 8567 cannot be represented in type 'int'CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace+0x214/0x230 show_stack+0x30/0x78 dump_stack_lvl+0xf8/0x118 dump_stack+0x18/0x30 ubsan_epilogue+0x18/0x60 handle_overflow+0xd0/0xf0 __ubsan_handle_add_overflow+0x34/0x44 __ip6_append_data.isra.48+0x1598/0x1688 ip6_append_data+0x128/0x260 udpv6_sendmsg+0x680/0xdd0 inet6_sendmsg+0x54/0x90 sock_sendmsg+0x70/0x88 ____sys_sendmsg+0xe8/0x368 ___sys_sendmsg+0x98/0xe0 __sys_sendmmsg+0xf4/0x3b8 __arm64_sys_sendmmsg+0x34/0x48 invoke_syscall+0x64/0x160 el0_svc_common.constprop.4+0x124/0x300 do_el0_svc+0x44/0xc8 el0_svc+0x3c/0x1e8 el0t_64_sync_handler+0x88/0xb0 el0t_64_sync+0x16c/0x170Changes since v1:-Change the variable [length] type to unsigned, as Eric Dumazet suggested.Changes since v2:-Don't change exthdrlen type in ip6_make_skb, as Paolo Abeni suggested.Changes since v3:-Don't change ulen type in udpv6_sendmsg and l2tp_ip6_sendmsg, asJakub Kicinski suggested.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53462 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:hsr: Fix uninit-value access in fill_frame_info()Syzbot reports the following uninit-value access problem.=====================================================BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:601 [inline]BUG: KMSAN: uninit-value in hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 fill_frame_info net/hsr/hsr_forward.c:601 [inline] hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4889 [inline] netdev_start_xmit include/linux/netdevice.h:4903 [inline] xmit_one net/core/dev.c:3544 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560 __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340 dev_queue_xmit include/linux/netdevice.h:3082 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x148/0x470 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:644 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2794 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82It is because VLAN not yet supported in hsr driver. Return errorwhen protocol is ETH_P_8021Q in fill_frame_info() now to fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53537 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid use-after-free for cached IPU bioxfstest generic/019 reports a bug:kernel BUG at mm/filemap.c:1619!RIP: 0010:folio_end_writeback+0x8a/0x90Call Trace: end_page_writeback+0x1c/0x60 f2fs_write_end_io+0x199/0x420 bio_endio+0x104/0x180 submit_bio_noacct+0xa5/0x510 submit_bio+0x48/0x80 f2fs_submit_write_bio+0x35/0x300 f2fs_submit_merged_ipu_write+0x2a0/0x2b0 f2fs_write_single_data_page+0x838/0x8b0 f2fs_write_cache_pages+0x379/0xa30 f2fs_write_data_pages+0x30c/0x340 do_writepages+0xd8/0x1b0 __writeback_single_inode+0x44/0x370 writeback_sb_inodes+0x233/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x2d0 wb_workfn+0x367/0x4a0 process_one_work+0x21d/0x430 worker_thread+0x4e/0x3c0 kthread+0x103/0x130 ret_from_fork+0x2c/0x50The root cause is: after cp_error is set, f2fs_submit_merged_ipu_write()in f2fs_write_single_data_page() tries to flush IPU bio in cache, howeverf2fs_submit_merged_ipu_write() missed to check validity of @bio parameter,result in submitting random cached bio which belong to other IO context,then it will cause use-after-free issue, fix it by adding additionalvalidity check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27025 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:nbd: null check for nla_nest_startnla_nest_start() may fail and return NULL. Insert a check and set errnobased on other call sites within the same source code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27051 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return valuecpufreq_cpu_get may return NULL. To avoid NULL-dereference check itand return 0 in case of error.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36916 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:blk-iocost: avoid out of bounds shiftUBSAN catches undefined behavior in blk-iocost, where sometimesiocg->delay is shifted right by a number that is too large,resulting in undefined behavior on some architectures.[ 186.556576] ------------[ cut here ]------------UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long')CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020Call Trace: dump_stack_lvl+0x8f/0xe0 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 iocg_kick_delay+0x30b/0x310 ioc_timer_fn+0x2fb/0x1f80 __run_timer_base+0x1b6/0x250...Avoid that undefined behavior by simply taking the"delay = 0" branch if the shift is too large.I am not sure what the symptoms of an undefined valuedelay will be, but I suspect it could be more than alittle annoying to debug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-39472 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: fix log recovery buffer allocation for the legacy h_size fixupCommit a70f9fe52daa ("xfs: detect and handle invalid iclog size set bymkfs") added a fixup for incorrect h_size values used for the initialumount record in old xfsprogs versions. Later commit 0c771b99d6c9("xfs: clean up calculation of LR header blocks") cleaned up the logreover buffer calculation, but stoped using the fixed up h_size valueto size the log recovery buffer, which can lead to an out of boundsaccess when the incorrect h_size does not come from the old mkfstool, but a fuzzer.Fix this by open coding xlog_logrec_hblks and taking the fixed h_sizeinto account for this calculation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42236 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()Userspace provided string 's' could trivially have the length zero. Leftunchecked this will firstly result in an OOB read in the form`if (str[0 - 1] == '\n') followed closely by an OOB write in the form`str[0 - 1] = '\0'`.There is already a validating check to catch strings that are too long.Let's supply an additional check for invalid strings that are too short.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47697 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write errorEnsure index in rtl2830_pid_filter does not exceed 31 to preventout-of-bounds access.dev->filters is a 32-bit value, so set_bit and clear_bit functions shouldonly operate on indices from 0 to 31. If index is 32, it will attempt toaccess a non-existent 33rd bit, leading to out-of-bounds access.Change the boundary check from index > 32 to index >= 32 to resolve thisissue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47698 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write errorEnsure index in rtl2832_pid_filter does not exceed 31 to preventout-of-bounds access.dev->filters is a 32-bit value, so set_bit and clear_bit functions shouldonly operate on indices from 0 to 31. If index is 32, it will attempt toaccess a non-existent 33rd bit, leading to out-of-bounds access.Change the boundary check from index > 32 to index >= 32 to resolve thisissue.[hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49894 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix index out of bounds in degamma hardware format translationFixes index out of bounds issue in`cm_helper_translate_curve_to_degamma_hw_format` function. The issuecould occur when the index 'i' exceeds the number of transfer functionpoints (TRANSFER_FUNC_POINTS).The fix adds a check to ensure 'i' is within bounds before accessing thetransfer function points. If 'i' is out of bounds the function returnsfalse to indicate an error.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50035 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: fix ppp_async_encode() illegal accesssyzbot reported an issue in ppp_async_encode() [1]In this case, pppoe_sendmsg() is called with a zero size.Then ppp_async_encode() is called with an empty skb.BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50148 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: bnep: fix wild-memory-access in proto_unregisterThere's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:proto_unregister+0xee/0x400 Call Trace: __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fAs bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init()will cleanup all resource. Then when remove bnep module will callbnep_sock_cleanup() to cleanup sock's resource.To solve above issue just return bnep_sock_init()'s return value inbnep_exit().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50150 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmode should keep reference to parentThe altmode device release refers to its parent device, but without keepinga reference to it.When registering the altmode, get a reference to the parent and put it inthe release function.Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issueslike this:[ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)[ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)[ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)[ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)[ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)[ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)[ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)[ 46.612867] ==================================================================[ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129[ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48[ 46.614538][ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535[ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014[ 46.616042] Workqueue: events kobject_delayed_cleanup[ 46.616446] Call Trace:[ 46.616648] [ 46.616820] dump_stack_lvl+0x5b/0x7c[ 46.617112] ? typec_altmode_release+0x38/0x129[ 46.617470] print_report+0x14c/0x49e[ 46.617769] ? rcu_read_unlock_sched+0x56/0x69[ 46.618117] ? __virt_addr_valid+0x19a/0x1ab[ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d[ 46.618807] ? typec_altmode_release+0x38/0x129[ 46.619161] kasan_report+0x8d/0xb4[ 46.619447] ? typec_altmode_release+0x38/0x129[ 46.619809] ? process_scheduled_works+0x3cb/0x85f[ 46.620185] typec_altmode_release+0x38/0x129[ 46.620537] ? process_scheduled_works+0x3cb/0x85f[ 46.620907] device_release+0xaf/0xf2[ 46.621206] kobject_delayed_cleanup+0x13b/0x17a[ 46.621584] process_scheduled_works+0x4f6/0x85f[ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10[ 46.622353] ? hlock_class+0x31/0x9a[ 46.622647] ? lock_acquired+0x361/0x3c3[ 46.622956] ? move_linked_works+0x46/0x7d[ 46.623277] worker_thread+0x1ce/0x291[ 46.623582] ? __kthread_parkme+0xc8/0xdf[ 46.623900] ? __pfx_worker_thread+0x10/0x10[ 46.624236] kthread+0x17e/0x190[ 46.624501] ? kthread+0xfb/0x190[ 46.624756] ? __pfx_kthread+0x10/0x10[ 46.625015] ret_from_fork+0x20/0x40[ 46.625268] ? __pfx_kthread+0x10/0x10[ 46.625532] ret_from_fork_asm+0x1a/0x30[ 46.625805] [ 46.625953][ 46.626056] Allocated by task 678:[ 46.626287] kasan_save_stack+0x24/0x44[ 46.626555] kasan_save_track+0x14/0x2d[ 46.626811] __kasan_kmalloc+0x3f/0x4d[ 46.627049] __kmalloc_noprof+0x1bf/0x1f0[ 46.627362] typec_register_port+0x23/0x491[ 46.627698] cros_typec_probe+0x634/0xbb6[ 46.628026] platform_probe+0x47/0x8c[ 46.628311] really_probe+0x20a/0x47d[ 46.628605] device_driver_attach+0x39/0x72[ 46.628940] bind_store+0x87/0xd7[ 46.629213] kernfs_fop_write_iter+0x1aa/0x218[ 46.629574] vfs_write+0x1d6/0x29b[ 46.629856] ksys_write+0xcd/0x13b[ 46.630128] do_syscall_64+0xd4/0x139[ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 46.630820][ 46.630946] Freed by task 48:[ 46.631182] kasan_save_stack+0x24/0x44[ 46.631493] kasan_save_track+0x14/0x2d[ 46.631799] kasan_save_free_info+0x3f/0x4d[ 46.632144] __kasan_slab_free+0x37/0x45[ 46.632474]---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50262 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix out-of-bounds write in trie_get_next_key()trie_get_next_key() allocates a node stack with size trie->max_prefixlen,while it writes (trie->max_prefixlen + 1) nodes to the stack when it hasfull paths from the root to leaves. For example, consider a trie withmax_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ...0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with.prefixlen = 8 make 9 nodes be written on the node stack with size 8.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50265 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():[ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12[ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry[ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004[...][ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0[...][ 57.331328] Call Trace:[ 57.331477] [...][ 57.333511] ? do_user_addr_fault+0x3e5/0x740[ 57.333778] ? exc_page_fault+0x70/0x170[ 57.334016] ? asm_exc_page_fault+0x2b/0x30[ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10[ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0[ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0[ 57.335164] ocfs2_xa_set+0x704/0xcf0[ 57.335381] ? _raw_spin_unlock+0x1a/0x40[ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20[ 57.335915] ? trace_preempt_on+0x1e/0x70[ 57.336153] ? start_this_handle+0x16c/0x500[ 57.336410] ? preempt_count_sub+0x50/0x80[ 57.336656] ? _raw_read_unlock+0x20/0x40[ 57.336906] ? start_this_handle+0x16c/0x500[ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0[ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0[ 57.337706] ? ocfs2_start_trans+0x13d/0x290[ 57.337971] ocfs2_xattr_set+0xb13/0xfb0[ 57.338207] ? dput+0x46/0x1c0[ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30[ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30[ 57.338948] __vfs_removexattr+0x92/0xc0[ 57.339182] __vfs_removexattr_locked+0xd5/0x190[ 57.339456] ? preempt_count_sub+0x50/0x80[ 57.339705] vfs_removexattr+0x5f/0x100[...]Reproducer uses faultinject facility to fail ocfs2_xa_remove() ->ocfs2_xa_value_truncate() with -ENOMEM.In this case the comment mentions that we can return 0 ifocfs2_xa_cleanup_value_truncate() is going to wipe the entryanyway. But the following 'rc' check is wrong and execution flow do'ocfs2_xa_remove_entry(loc);' twice:* 1st: in ocfs2_xa_cleanup_value_truncate();* 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'.Fix this by skipping the 2nd removal of the same entry and makingsyzkaller repro happy.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53150 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix out of bounds reads when finding clock sourcesThe current USB-audio driver code doesn't check bLength of eachdescriptor at traversing for clock descriptors. That is, when adevice provides a bogus descriptor with a shorter bLength, the drivermight hit out-of-bounds reads.For addressing it, this patch adds sanity checks to the validatorfunctions for the clock descriptor traversal. When the descriptorlength is shorter than expected, it's skipped in the loop.For the clock source and clock multiplier descriptors, we can justcheck bLength against the sizeof() of each descriptor type.OTOH, the clock selector descriptor of UAC2 and UAC3 has an arrayof bNrInPins elements and two more fields at its tail, hence thosehave to be checked in addition to the sizeof() check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53162 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat/qat_4xxx - fix off by one in uof_get_name()The fw_objs[] array has "num_objs" elements so the > needs to be >= toprevent an out of bounds read.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53203 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: fix potential array underflow in ucsi_ccg_sync_control()The "command" variable can be controlled by the user via debugfs. Theworry is that if con_index is zero then "&uc->ucsi->connector[con_index- 1]" would be an array underflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53216 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: release svc_expkey/svc_export with rcu_workThe last reference for `cache_head` can be reduced to zero in `c_show`and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently,`svc_export_put` and `expkey_put` will be invoked, leading to twoissues:1. The `svc_export_put` will directly free ex_uuid. However, `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can trigger a use-after-free issue, shown below. ================================================================== BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870 CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_address_description.constprop.0+0x2c/0x3a0 print_report+0xb9/0x280 kasan_report+0xae/0xe0 svc_export_show+0x362/0x430 [nfsd] c_show+0x161/0x390 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 830: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_node_track_caller_noprof+0x1bc/0x400 kmemdup_noprof+0x22/0x50 svc_export_parse+0x8a9/0xb80 [nfsd] cache_do_downcall+0x71/0xa0 [sunrpc] cache_write_procfs+0x8e/0xd0 [sunrpc] proc_reg_write+0xe1/0x140 vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 868: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kfree+0xf3/0x3e0 svc_export_put+0x87/0xb0 [nfsd] cache_purge+0x17f/0x1f0 [sunrpc] nfsd_destroy_serv+0x226/0x2d0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`. However, `svc_export_put`/`expkey_put` will call path_put, which subsequently triggers a sleeping operation due to the following `dput`. ============================= WARNING: suspicious RCU usage 5.10.0-dirty #141 Not tainted ----------------------------- ... Call Trace: dump_stack+0x9a/0xd0 ___might_sleep+0x231/0x240 dput+0x39/0x600 path_put+0x1b/0x30 svc_export_put+0x17/0x80 e_show+0x1c9/0x200 seq_read_iter+0x63f/0x7c0 seq_read+0x226/0x2d0 vfs_read+0x113/0x2c0 ksys_read+0xc9/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1Fix these issues by using `rcu_work` to help release`svc_expkey`/`svc_export`. This approach allows for an asynchronouscontext to invoke `path_put` and also facilitates the freeing of`uuid/exp/key` after an RCU grace period.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56662 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctlFix an issue detected by syzbot with KASAN:BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/core.c:416 [inline]BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0drivers/acpi/nfit/core.c:459The issue occurs in cmd_to_func when the call_pkg->nd_reserved2array is accessed without verifying that call_pkg points to a bufferthat is appropriately sized as a struct nd_cmd_pkg. This can leadto out-of-bounds access and undefined behavior if the buffer does nothave sufficient space.To address this, a check was added in acpi_nfit_ctl() to ensure thatbuf is not NULL and that buf_len is less than sizeof(*call_pkg)before accessing it. This ensures safe access to the members ofcall_pkg, including the nd_reserved2 array.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57890 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/uverbs: Prevent integer overflow issueIn the expression "cmd.wqe_size * cmd.wr_count", both variables are u32values that come from the user so the multiplication can lead to integerwrapping. Then we pass the result to uverbs_request_next_ptr() which alsocould potentially wrap. The "cmd.sge_count * sizeof(struct ib_uverbs_sge)"multiplication can also overflow on 32bit systems although it's fine on64bit systems.This patch does two things. First, I've re-arranged the condition inuverbs_request_next_ptr() so that the use controlled variable "len" is onone side of the comparison by itself without any math. Then I've modifiedall the callers to use size_mul() for the multiplications.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58017 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAXShifting 1 << 31 on a 32-bit int causes signed integer overflow, whichleads to undefined behavior. To prevent this, cast 1 to u32 beforeperforming the shift, ensuring well-defined behavior.This change explicitly avoids any potential overflow by ensuring thatthe shift occurs on an unsigned 32-bit integer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
libtasn1 > 0-0 (version in image is 4.13-150000.4.14.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/rose: prevent integer overflows in rose_setsockopt()In case of possible unpredictably large arguments passed torose_setsockopt() and multiplied by extra values on top of that,integer overflows may occur.Do the safest minimum and fix these issues by checking thecontents of 'opt' and returning -EINVAL if they are too large. Also,switch to unsigned int and remove useless check for negative 'opt'in ROSE_IDLE case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: add missing rcu read protection for procfs contentWhen the procfs content is generated for a bcm_op which is in the processto be removed the procfs output might show unreliable data (UAF).As the removal of bcm_op's is already implemented with rcu handling thispatch adds the missing rcu_read_lock() and makes sure the list entriesare properly removed under rcu protection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: prevent overflow in lookup table allocationWhen calculating the lookup table size, ensure the followingmultiplication does not overflow:- desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.- NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case.- sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field.Then, use check_mul_overflow() to multiply by bucket size and then usecheck_add_overflow() to the alignment for avx2 (if needed). Finally, addlt_size_check_overflow() helper and use it to consolidate this.While at it, replace leftover allocation using the GFP_KERNEL toGFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix ktls panic with sockmap[ 2172.936997] ------------[ cut here ]------------[ 2172.936999] kernel BUG at lib/iov_iter.c:629!......[ 2172.944996] PKRU: 55555554[ 2172.945155] Call Trace:[ 2172.945299] [ 2172.945428] ? die+0x36/0x90[ 2172.945601] ? do_trap+0xdd/0x100[ 2172.945795] ? iov_iter_revert+0x178/0x180[ 2172.946031] ? iov_iter_revert+0x178/0x180[ 2172.946267] ? do_error_trap+0x7d/0x110[ 2172.946499] ? iov_iter_revert+0x178/0x180[ 2172.946736] ? exc_invalid_op+0x50/0x70[ 2172.946961] ? iov_iter_revert+0x178/0x180[ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20[ 2172.947446] ? iov_iter_revert+0x178/0x180[ 2172.947683] ? iov_iter_revert+0x5c/0x180[ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840[ 2172.948206] tls_sw_sendmsg+0x52/0x80[ 2172.948420] ? inet_sendmsg+0x1f/0x70[ 2172.948634] __sys_sendto+0x1cd/0x200[ 2172.948848] ? find_held_lock+0x2b/0x80[ 2172.949072] ? syscall_trace_enter+0x140/0x270[ 2172.949330] ? __lock_release.isra.0+0x5e/0x170[ 2172.949595] ? find_held_lock+0x2b/0x80[ 2172.949817] ? syscall_trace_enter+0x140/0x270[ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190[ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0[ 2172.951036] __x64_sys_sendto+0x24/0x30[ 2172.951382] do_syscall_64+0x90/0x170......After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase,e.g., when the BPF program executes bpf_msg_push_data().If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,it will return -ENOSPC and attempt to roll back to the non-zero copylogic. However, during rollback, msg->msg_iter is reset, but sincemsg_pl->sg.size has been increased, subsequent executions will exceed theactual size of msg_iter.'''iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size);'''The changes in this commit are based on the following considerations:1. When cork_bytes is set, rolling back to non-zero copy logic ispointless and can directly go to zero-copy logic.2. We can not calculate the correct number of bytes to revert msg_iter.Assume the original data is "abcdefgh" (8 bytes), and after 3 pushesby the BPF program, it becomes 11-byte data: "abc?de?fgh?".Then, we set cork_bytes to 6, which means the first 6 bytes have beenprocessed, and the remaining 5 bytes "?fgh?" will be cached until thelength meets the cork_bytes requirement.However, some data in "?fgh?" is not within 'sg->msg_iter'(but in msg_pl instead), especially the data "?" we pushed.So it doesn't seem as simple as just reverting through an offset ofmsg_iter.3. For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs,the user-space send() doesn't return an error, and the returned length isthe same as the input length parameter, even if some data is cached.Additionally, I saw that the current non-zero-copy logic for handlingcorking is written as:'''line 1177else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end;'''So it's ok to just return 'copied' without error when a "cork" situationoccurs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:PCI/IOV: Fix race between SR-IOV enable/disable and hotplugCommit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking whenenabling/disabling SR-IOV") tried to fix a race between the VF removalinside sriov_del_vfs() and concurrent hot unplug by taking the PCIrescan/remove lock in sriov_del_vfs(). Similarly the PCI rescan/remove lockwas also taken in sriov_add_vfs() to protect addition of VFs.This approach however causes deadlock on trying to remove PFs with SR-IOVenabled because PFs disable SR-IOV during removal and this removal happensunder the PCI rescan/remove lock. So the original fix had to be reverted.Instead of taking the PCI rescan/remove lock in sriov_add_vfs() andsriov_del_vfs(), fix the race that occurs with SR-IOV enable and disable vshotplug higher up in the callchain by taking the lock insriov_numvfs_store() before calling into the driver's sriov_configure()callback.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: net-tools is a collection of programs that form the base set of the NET-3 networking distribution for the Linux operating system. Inn versions up to and including 2.10, the Linux network utilities (like ifconfig) from the net-tools package do not properly validate the structure of /proc files when showing interfaces. `get_name()` in `interface.c` copies interface labels from `/proc/net/dev` into a fixed 16-byte stack buffer without bounds checking, leading to possible arbitrary code execution or crash. The known attack path does not require privilege but also does not provide privilege escalation in this scenario. A patch is available and expected to be part of version 2.20.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
net-tools > 0-0 (version in image is 2.0+git20170221.479bb4a-150000.5.13.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - zero initialize memory allocated via sock_kmallocSeveral crypto user API contexts and requests allocated withsock_kmalloc() were left uninitialized, relying on callers toset fields explicitly. This resulted in the use of uninitializeddata in certain error paths or when new fields are added in thefuture.The ACVP patches also contain two user-space interface files:algif_kpp.c and algif_akcipher.c. These too rely on properinitialization of their context structures.A particular issue has been observed with the newly added'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")Because the context is not memset to zero after allocation,the inflight variable has contained garbage values. As a result,af_alg_alloc_areq() has incorrectly returned -EBUSY randomly whenthe garbage value was interpreted as true: https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209The check directly tests ctx->inflight without explicitlycomparing against true/false. Since inflight is only ever set totrue or false later, an uninitialized value has triggered-EBUSY failures. Zero-initializing memory allocated withsock_kmalloc() ensures inflight and other fields start in a knownstate, removing random issues caused by uninitialized data.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardwareplatforms, it has already started the EC and installed the addressspace handler with the struct acpi_ec pointer as handler context.However, acpi_ec_setup() propagates the error without any cleanup.The caller acpi_ec_add() then frees the struct acpi_ec for non-bootinstances, leaving a dangling handler context in ACPICA.Any subsequent AML evaluation that accesses an EC OpRegion fielddispatches into acpi_ec_space_handler() with the freed pointer,causing a use-after-free: BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289) Write of size 8 at addr ffff88800721de38 by task init/1 Call Trace: mutex_lock (kernel/locking/mutex.c:289) acpi_ec_space_handler (drivers/acpi/ec.c:1362) acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293) acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246) acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509) acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700) acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327) acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392) Allocated by task 1: acpi_ec_alloc (drivers/acpi/ec.c:1424) acpi_ec_add (drivers/acpi/ec.c:1692) Freed by task 1: kfree (mm/slub.c:6876) acpi_ec_add (drivers/acpi/ec.c:1751)The bug triggers on reduced-hardware EC platforms (ec->gpe < 0)when the GPIO IRQ provider defers probing. Once the stale handlerexists, any unprivileged sysfs read that causes AML to touch anEC OpRegion (battery, thermal, backlight) exercises the danglingpointer.Fix this by calling ec_remove_handlers() in the error path ofacpi_ec_setup() before clearing first_ec. ec_remove_handlers()checks each EC_FLAGS_* bit before acting, so it is safe to callregardless of how far ec_install_handlers() progressed: -ENODEV (handler not installed): only calls acpi_ec_stop() -EPROBE_DEFER (handler installed): removes handler, stops EC

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: jq is a command-line JSON processor. In 1.8.1 and earlier, jv_contains recurses into nested arrays/objects with no depth limit. With a sufficiently nested input structure (built programmatically with reduce, since the JSON parser caps at depth 10000), the C stack is exhausted.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
jq > 0-0 (version in image is 1.6-150000.3.12.1).

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

Description: Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.2.0280-150000.5.89.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: fix pass-by-value structs causing MSAN warningsvidtv_ts_null_write_into() and vidtv_ts_pcr_write_into() take theirargument structs by value, causing MSAN to report uninit-value warnings.While only vidtv_ts_null_write_into() has triggered a report so far,both functions share the same issue.Fix by passing both structs by const pointer instead, avoiding thestack copy of the struct along with its MSAN shadow and origin metadata.The functions do not modify the structs, which is enforced by the constqualifier.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix transaction abort on set received ioctl due to item overflowIf the set received ioctl fails due to an item overflow when attempting toadd the BTRFS_UUID_KEY_RECEIVED_SUBVOL we have to abort the transactionsince we did some metadata updates before.This means that if a user calls this ioctl with the same received UUIDfield for a lot of subvolumes, we will hit the overflow, trigger thetransaction abort and turn the filesystem into RO mode. A malicious usercould exploit this, and this ioctl does not even requires that a userhas admin privileges (CAP_SYS_ADMIN), only that he/she owns the subvolume.Fix this by doing an early check for item overflow before starting atransaction. This is also race safe because we are holding the subvol_semsemaphore in exclusive (write) mode.A test case for fstests will follow soon.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: Vim is an open source, command line text editor. Prior to version 9.2.0450, a heap buffer overflow exists in read_compound() in src/spellfile.c when loading a crafted spell file (.spl) with UTF-8 encoding active. An attacker-controlled length field in the spell file's compound section overflows a 32-bit signed integer multiplication, causing a small buffer to be allocated for a write loop that runs many iterations, overflowing the heap. Because the 'spelllang' option can be set from a modeline, a text file modeline can trigger spell file loading if a malicious .spl file has been planted on the runtimepath. This issue has been patched in version 9.2.0450.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim < 9.2.0530-150000.5.94.1 (version in image is 9.2.0280-150000.5.89.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: caiaq: Handle probe errors properlyThe probe procedure of setup_card() in caiaq driver doesn't treat theerror cases gracefully, e.g. the error from snd_card_register() callssnd_card_free() but continues. This would lead to a UAF for thefurther calls like snd_usb_caiaq_control_init(), as Berk suggested inanother patch in the link below.However, the problem is not only that; in general, this function dropsthe all error handlings (as it's a void function) although its callercan propagate an error to snd_probe(), which eventually callssnd_card_free() as a proper error path. That said, we should treateach error case in setup_card(), and just return the error codepromptly, which is then handled later as a fatal error in snd_probe().This patch achieves it by changing the setup_card() to return an errorcode. Also, the superfluous snd_card_free() call is removed, too.Note that card->private_free can be set still safely at returning anerror. All called functions in card_free() have checks of theunassigned resources or NULL checks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: reject zero shift in nft_bitwiseReject zero shift operands for nft_bitwise left and right shiftexpressions during initialization.The carry propagation logic computes the carry from the adjacent 32-bitword using BITS_PER_TYPE(u32) - shift. A zero shift operand turns thisinto a 32-bit shift, which is undefined behaviour.Reject zero shift operands in the control plane, alongside the existingcheck for values greater than or equal to 32, so malformed rules neverreach the packet path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2019-13225 Severity: Moderate CVSS3 score: 6.5

Description: A NULL Pointer Dereference in match_at() in regexec.c in Oniguruma 6.9.2 allows attackers to potentially cause denial of service by providing a crafted regular expression. Oniguruma issues often affect Ruby, as well as common optional libraries for PHP and Rust.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libonig4 > 0-0 (version in image is 6.7.0-150000.3.6.1).

CVE-2021-47517 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: do not perform operations on net devices being unregisteredThere is a short period between a net device starts to be unregisteredand when it is actually gone. In that time frame ethtool operationscould still be performed, which might end up in unwanted or undefinedbehaviours[1].Do not allow ethtool operations after a net device starts itsunregistration. This patch targets the netlink part as the ioctl oneisn't affected: the reference to the net device is taken and theoperation is executed within an rtnl lock section and the net devicewon't be found after unregister.[1] For example adding Tx queues after unregister ends up in NULL pointer exceptions and UaFs, such as: BUG: KASAN: use-after-free in kobject_get+0x14/0x90 Read of size 1 at addr ffff88801961248c by task ethtool/755 CPU: 0 PID: 755 Comm: ethtool Not tainted 5.15.0-rc6+ #778 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/014 Call Trace: dump_stack_lvl+0x57/0x72 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x7f/0x11b kobject_get+0x14/0x90 kobject_add_internal+0x3d1/0x450 kobject_init_and_add+0xba/0xf0 netdev_queue_update_kobjects+0xcf/0x200 netif_set_real_num_tx_queues+0xb4/0x310 veth_set_channels+0x1c3/0x550 ethnl_set_channels+0x524/0x610

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In ssh in OpenSSH before 9.6, OS command injection might occur if a user name or host name has shell metacharacters, and this name is referenced by an expansion token in certain situations. For example, an untrusted Git repository can have a submodule with shell metacharacters in a user name or host name.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
openssh > 0-0 (version in image is 8.4p1-150300.3.60.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential OOBs in smb2_parse_contexts()Validate offsets and lengths before dereferencing create contexts insmb2_parse_contexts().This fixes following oops when accessing invalid create contexts fromserver: BUG: unable to handle page fault for address: ffff8881178d8cc3 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 4a01067 P4D 4a01067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs] Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00 00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7 7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00 RSP: 0018:ffffc900007939e0 EFLAGS: 00010216 RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90 RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000 RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000 R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000 R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22 FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x181/0x480 ? search_module_extables+0x19/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x1b6/0x1c0 ? asm_exc_page_fault+0x26/0x30 ? smb2_parse_contexts+0xa0/0x3a0 [cifs] SMB2_open+0x38d/0x5f0 [cifs] ? smb2_is_path_accessible+0x138/0x260 [cifs] smb2_is_path_accessible+0x138/0x260 [cifs] cifs_is_path_remote+0x8d/0x230 [cifs] cifs_mount+0x7e/0x350 [cifs] cifs_smb3_do_mount+0x128/0x780 [cifs] smb3_get_tree+0xd9/0x290 [cifs] vfs_get_tree+0x2c/0x100 ? capable+0x37/0x70 path_mount+0x2d7/0xb80 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __x64_sys_mount+0x11a/0x150 do_syscall_64+0x47/0xf0 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f8737657b1e

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: check send stream number after wait_for_sndbufThis patch fixes a corner case where the asoc out stream count may changeafter wait_for_sndbuf.When the main thread in the client starts a connection, if its out streamcount is set to N while the in stream count in the server is set to N - 2,another thread in the client keeps sending the msgs with stream numberN - 1, and waits for sndbuf before processing INIT_ACK.However, after processing INIT_ACK, the out stream count in the client isshrunk to N - 2, the same to the in stream count in the server. The crashoccurs when the thread waiting for sndbuf is awake and sends the msg in anon-existing stream(N - 1), the call trace is as below: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] Call Trace: sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline] sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline] sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170 sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163 sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868 sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026 inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825 sock_sendmsg_nosec net/socket.c:722 [inline] sock_sendmsg+0xde/0x190 net/socket.c:745The fix is to add an unlikely check for the send stream number after thethread wakes up from the wait_for_sndbuf.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: do not update mtu if msg_max is too small in mtu negotiationWhen doing link mtu negotiation, a malicious peer may send Activate msgwith a very small mtu, e.g. 4 in Shuang's testing, without checking forthe minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), thenn->links[bearer_id].mtu is set to 4294967228, which is a overflow of'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning: tipc: Too large msg, purging xmit list 1 5 0 40 4! tipc: Too large msg, purging xmit list 1 15 0 60 4!And with tipc_link_entry.mtu 4294967228, a huge skb was allocated innamed_distribute(), and when purging it in tipc_link_xmit(), a crashwas even caused: general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19 RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0 Call Trace: skb_release_data+0xf9/0x1d0 kfree_skb_reason+0x40/0x100 tipc_link_xmit+0x57a/0x740 [tipc] tipc_node_xmit+0x16c/0x5c0 [tipc] tipc_named_node_up+0x27f/0x2c0 [tipc] tipc_node_write_unlock+0x149/0x170 [tipc] tipc_rcv+0x608/0x740 [tipc] tipc_udp_recv+0xdc/0x1f0 [tipc] udp_queue_rcv_one_skb+0x33e/0x620 udp_unicast_rcv_skb.isra.72+0x75/0x90 __udp4_lib_rcv+0x56d/0xc20 ip_protocol_deliver_rcu+0x100/0x2d0This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),and not updating mtu if it is too small.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix incomplete state save in rxe_requesterIf a send packet is dropped by the IP layer in rxe_requester()the call to rxe_xmit_packet() can fail with err == -EAGAIN.To recover, the state of the wqe is restored to the state beforethe packet was sent so it can be resent. However, the routinesthat save and restore the state miss a significnt part of thevariable state in the wqe, the dma struct which is used to processthrough the sge table. And, the state is not saved before the packetis built which modifies the dma struct.Under heavy stress testing with many QPs on a fast node sendinglarge messages to a slow node dropped packets are observed andthe resent packets are corrupted because the dma struct was notrestored. This patch fixes this behavior and allows the test casesto succeed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: qmi_encdec: Restrict string length in decodeThe QMI TLV value for strings in a lot of qmi element info structuresaccount for null terminated strings with MAX_LEN + 1. If a string isactually MAX_LEN + 1 length, this will cause an out of bounds accesswhen the NULL character is appended in decoding.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: cls_api: remove block_cb from driver_list before freeingError handler of tcf_block_bind() frees the whole bo->cb_list on error.However, by that time the flow_block_cb instances are already in the driverlist because driver ndo_setup_tc() callback is called before that up thecall chain in tcf_block_offload_cmd(). This leaves dangling pointers tofreed objects in the list and causes use-after-free[0]. Fix it by alsoremoving flow_block_cb instances from driver_list before deallocating them.[0]:[ 279.868433] ==================================================================[ 279.869964] BUG: KASAN: slab-use-after-free in flow_block_cb_setup_simple+0x631/0x7c0[ 279.871527] Read of size 8 at addr ffff888147e2bf20 by task tc/2963[ 279.873151] CPU: 6 PID: 2963 Comm: tc Not tainted 6.3.0-rc6+ #4[ 279.874273] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 279.876295] Call Trace:[ 279.876882] [ 279.877413] dump_stack_lvl+0x33/0x50[ 279.878198] print_report+0xc2/0x610[ 279.878987] ? flow_block_cb_setup_simple+0x631/0x7c0[ 279.879994] kasan_report+0xae/0xe0[ 279.880750] ? flow_block_cb_setup_simple+0x631/0x7c0[ 279.881744] ? mlx5e_tc_reoffload_flows_work+0x240/0x240 [mlx5_core][ 279.883047] flow_block_cb_setup_simple+0x631/0x7c0[ 279.884027] tcf_block_offload_cmd.isra.0+0x189/0x2d0[ 279.885037] ? tcf_block_setup+0x6b0/0x6b0[ 279.885901] ? mutex_lock+0x7d/0xd0[ 279.886669] ? __mutex_unlock_slowpath.constprop.0+0x2d0/0x2d0[ 279.887844] ? ingress_init+0x1c0/0x1c0 [sch_ingress][ 279.888846] tcf_block_get_ext+0x61c/0x1200[ 279.889711] ingress_init+0x112/0x1c0 [sch_ingress][ 279.890682] ? clsact_init+0x2b0/0x2b0 [sch_ingress][ 279.891701] qdisc_create+0x401/0xea0[ 279.892485] ? qdisc_tree_reduce_backlog+0x470/0x470[ 279.893473] tc_modify_qdisc+0x6f7/0x16d0[ 279.894344] ? tc_get_qdisc+0xac0/0xac0[ 279.895213] ? mutex_lock+0x7d/0xd0[ 279.896005] ? __mutex_lock_slowpath+0x10/0x10[ 279.896910] rtnetlink_rcv_msg+0x5fe/0x9d0[ 279.897770] ? rtnl_calcit.isra.0+0x2b0/0x2b0[ 279.898672] ? __sys_sendmsg+0xb5/0x140[ 279.899494] ? do_syscall_64+0x3d/0x90[ 279.900302] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0[ 279.901337] ? kasan_save_stack+0x2e/0x40[ 279.902177] ? kasan_save_stack+0x1e/0x40[ 279.903058] ? kasan_set_track+0x21/0x30[ 279.903913] ? kasan_save_free_info+0x2a/0x40[ 279.904836] ? ____kasan_slab_free+0x11a/0x1b0[ 279.905741] ? kmem_cache_free+0x179/0x400[ 279.906599] netlink_rcv_skb+0x12c/0x360[ 279.907450] ? rtnl_calcit.isra.0+0x2b0/0x2b0[ 279.908360] ? netlink_ack+0x1550/0x1550[ 279.909192] ? rhashtable_walk_peek+0x170/0x170[ 279.910135] ? kmem_cache_alloc_node+0x1af/0x390[ 279.911086] ? _copy_from_iter+0x3d6/0xc70[ 279.912031] netlink_unicast+0x553/0x790[ 279.912864] ? netlink_attachskb+0x6a0/0x6a0[ 279.913763] ? netlink_recvmsg+0x416/0xb50[ 279.914627] netlink_sendmsg+0x7a1/0xcb0[ 279.915473] ? netlink_unicast+0x790/0x790[ 279.916334] ? iovec_from_user.part.0+0x4d/0x220[ 279.917293] ? netlink_unicast+0x790/0x790[ 279.918159] sock_sendmsg+0xc5/0x190[ 279.918938] ____sys_sendmsg+0x535/0x6b0[ 279.919813] ? import_iovec+0x7/0x10[ 279.920601] ? kernel_sendmsg+0x30/0x30[ 279.921423] ? __copy_msghdr+0x3c0/0x3c0[ 279.922254] ? import_iovec+0x7/0x10[ 279.923041] ___sys_sendmsg+0xeb/0x170[ 279.923854] ? copy_msghdr_from_user+0x110/0x110[ 279.924797] ? ___sys_recvmsg+0xd9/0x130[ 279.925630] ? __perf_event_task_sched_in+0x183/0x470[ 279.926656] ? ___sys_sendmsg+0x170/0x170[ 279.927529] ? ctx_sched_in+0x530/0x530[ 279.928369] ? update_curr+0x283/0x4f0[ 279.929185] ? perf_event_update_userpage+0x570/0x570[ 279.930201] ? __fget_light+0x57/0x520[ 279.931023] ? __switch_to+0x53d/0xe70[ 27---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set page extent mapped after read_folio in relocate_one_pageOne of the CI runs triggered the following panic assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 ------------[ cut here ]------------ kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 PID: 923660 Comm: btrfs Not tainted 6.5.0-rc3+ #1 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 sp : ffff800093213720 x29: ffff800093213720 x28: ffff8000932138b4 x27: 000000000c280000 x26: 00000001b5d00000 x25: 000000000c281000 x24: 000000000c281fff x23: 0000000000001000 x22: 0000000000000000 x21: ffffff42b95bf880 x20: ffff42b9528e0000 x19: 0000000000001000 x18: ffffffffffffffff x17: 667274622f736620 x16: 6e69202c65746176 x15: 0000000000000028 x14: 0000000000000003 x13: 00000000002672d7 x12: 0000000000000000 x11: ffffcd3f0ccd9204 x10: ffffcd3f0554ae50 x9 : ffffcd3f0379528c x8 : ffff800093213428 x7 : 0000000000000000 x6 : ffffcd3f091771e8 x5 : ffff42b97f333948 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff42b9556cde80 x0 : 000000000000004f Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_set_dirty+0x38/0xa0 btrfs_page_set_dirty+0x58/0x88 relocate_one_page+0x204/0x5f0 relocate_file_extent_cluster+0x11c/0x180 relocate_data_extent+0xd0/0xf8 relocate_block_group+0x3d0/0x4e8 btrfs_relocate_block_group+0x2d8/0x490 btrfs_relocate_chunk+0x54/0x1a8 btrfs_balance+0x7f4/0x1150 btrfs_ioctl+0x10f0/0x20b8 __arm64_sys_ioctl+0x120/0x11d8 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x158 el0_svc+0x50/0x1b0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198 Code: 91098021 b0007fa0 91346000 97e9c6d2 (d4210000)This is the same problem outlined in 17b17fcd6d44 ("btrfs:set_page_extent_mapped after read_folio in btrfs_cont_expand") , and thefix is the same. I originally looked for the same pattern elsewhere inour code, but mistakenly skipped over this code because I saw the pagecache readahead before we set_page_extent_mapped, not realizing thatthis was only in the !page case, that we can still end up with a!uptodate page and then do the btrfs_read_folio further down.The fix here is the same as the above mentioned patch, move theset_page_extent_mapped call to after the btrfs_read_folio() block tomake sure that we have the subpage blocksize stuff setup properly beforeusing the page.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-2398 Severity: Moderate CVSS3 score: 6.5

Description: When an application tells libcurl it wants to allow HTTP/2 server push, and the amount of received headers for the push surpasses the maximum allowed limit (1000), libcurl aborts the server push. When aborting, libcurl inadvertently does not free all the previously allocated headers and instead leaks the memory. Further, this error condition fails silently and is therefore not easily detected by an application.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.83.1).

CVE-2024-27415 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: confirm multicast packets before passing them up the stackconntrack nf_confirm logic cannot handle cloned skbs referencingthe same nf_conn entry, which will happen for multicast (broadcast)frames on bridges. Example: macvlan0 | br0 / \ ethX ethY ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table. 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting. -> skb->_nfct now references a unconfirmed entry 2. skb is broad/mcast packet. bridge now passes clones out on each bridge interface. 3. skb gets passed up the stack. 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices. The clone skb->_nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RX_HANDLER_PASS. 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.The Macvlan broadcast worker and normal confirm path will race.This race will not happen if step 2 already confirmed a clone. In thatcase later steps perform skb_clone() with skb->_nfct already confirmed (inhash table). This works fine.But such confirmation won't happen when eb/ip/nftables rules dropped thepackets before they reached the nf_confirm step in postrouting.Pablo points out that nf_conntrack_bridge doesn't allow use of statefulnat, so we can safely discard the nf_conn entry and let inet callconntrack again.This doesn't work for bridge netfilter: skb could have a nattransformation. Also bridge nf prevents re-invocation of inet preroutingvia 'sabotage_in' hook.Work around this problem by explicit confirmation of the entry at LOCAL_INtime, before upper layer has a chance to clone the unconfirmed entry.The downside is that this disables NAT and conntrack helpers.Alternative fix would be to add locking to all code parts that deal withunconfirmed packets, but even if that could be done in a sane way thisopens up other problems, for example:-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5For multicast case, only one of such conflicting mappings will becreated, conntrack only handles 1:1 NAT mappings.Users should set create a setup that explicitly marks such trafficNOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypassthem, ruleset might have accept rules for untracked traffic already,so user-visible behaviour would change.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-3651 Severity: Moderate CVSS3 score: 6.5

Description: A vulnerability was identified in the kjd/idna library, specifically within the `idna.encode()` function, affecting version 3.6. The issue arises from the function's handling of crafted input strings, which can lead to quadratic complexity and consequently, a denial of service condition. This vulnerability is triggered by a crafted input that causes the `idna.encode()` function to process the input with considerable computational load, significantly increasing the processing time in a quadratic manner relative to the input size.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-idna > 0-0 (version in image is 3.4-150400.11.10.1).

CVE-2024-41048 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:skmsg: Skip zero length skb in sk_msg_recvmsgWhen running BPF selftests (./test_progs -t sockmap_basic) on a Loongarchplatform, the following kernel panic occurs: [...] Oops[#1]: CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+ #18 Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018 ... ... ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560 ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 0000000c (PPLV0 +PIE +PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) BADV: 0000000000000040 PRID: 0014c011 (Loongson-64bit, Loongson-3C5000) Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...) Stack : ... Call Trace: [<9000000004162774>] copy_page_to_iter+0x74/0x1c0 [<90000000048bf6c0>] sk_msg_recvmsg+0x120/0x560 [<90000000049f2b90>] tcp_bpf_recvmsg_parser+0x170/0x4e0 [<90000000049aae34>] inet_recvmsg+0x54/0x100 [<900000000481ad5c>] sock_recvmsg+0x7c/0xe0 [<900000000481e1a8>] __sys_recvfrom+0x108/0x1c0 [<900000000481e27c>] sys_recvfrom+0x1c/0x40 [<9000000004c076ec>] do_syscall+0x8c/0xc0 [<9000000003731da4>] handle_syscall+0xc4/0x160 Code: ... ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception Kernel relocated by 0x3510000 .text @ 0x9000000003710000 .data @ 0x9000000004d70000 .bss @ 0x9000000006469400 ---[ end Kernel panic - not syncing: Fatal exception ]--- [...]This crash happens every time when running sockmap_skb_verdict_shutdownsubtest in sockmap_basic.This crash is because a NULL pointer is passed to page_address() in thesk_msg_recvmsg(). Due to the different implementations depending on thearchitecture, page_address(NULL) will trigger a panic on Loongarchplatform but not on x86 platform. So this bug was hidden on x86 platformfor a while, but now it is exposed on Loongarch platform. The root causeis that a zero length skb (skb->len == 0) was put on the queue.This zero length skb is a TCP FIN packet, which was sent by shutdown(),invoked in test_sockmap_skb_verdict_shutdown(): shutdown(p1, SHUT_WR);In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and nopage is put to this sge (see sg_set_page in sg_set_page), but this emptysge is queued into ingress_msg list.And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got bysg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes itto kmap_local_page() and to page_address(), then kernel panics.To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),if copy is zero, that means it's a zero length skb, skip invokingcopy_page_to_iter(). We are using the EFAULT return triggered bycopy_page_to_iter to check for is_fin in tcp_bpf.c.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46737 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: fix kernel crash if commands allocation failsIf the commands allocation fails in nvmet_tcp_alloc_cmds()the kernel crashes in nvmet_tcp_release_queue_work() because ofa NULL pointer dereference. nvmet: failed to install queue 0 cntlid 1 ret 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008Fix the bug by setting queue->nr_cmds to zero in casenvmet_tcp_alloc_cmd() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47685 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sendinggarbage on the four reserved tcp bits (th->res1)Use skb_put_zero() to clear the whole TCP header,as done in nf_reject_ip_tcphdr_put()BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-8096 Severity: Moderate CVSS3 score: 6.5

Description: When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine. If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.83.1).

CVE-2024-9287 Severity: Moderate CVSS3 score: 6.5

Description: A vulnerability has been found in the CPython `venv` module and CLI where path names provided when creating a virtual environment were not quoted properly, allowing the creator to inject commands into virtual environment "activation" scripts (ie "source venv/bin/activate"). This means that attacker-controlled virtual environments are able to run commands when the virtual environment is activated. Virtual environments which are not created by an attacker or which aren't activated before being used (ie "./venv/bin/python") are not affected.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).

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

Description: URLs containing percent-encoded slashes (`/` or `\`) can trick wcurl intosaving the output file outside of the current directory without the userexplicitly asking for it.This flaw only affects the wcurl command line tool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.83.1).

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

Description: A vulnerability was recently discovered in the rpc.mountd daemon in the nfs-utils package for Linux, that allows a NFSv3 client to escalate theprivileges assigned to it in the /etc/exports file at mount time. In particular, it allows the client to access any subdirectory or subtree of an exported directory, regardless of the set file permissions, and regardless of any 'root_squash' or 'all_squash' attributes that would normally be expected to apply to that client.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
nfs-client > 0-0 (version in image is 2.1.1-150100.10.37.1).

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).

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

Description: In MIT Kerberos 5 (aka krb5) before 1.22 (with incremental propagation), there is an integer overflow for a large update size to resize() in kdb_log.c. An authenticated attacker can cause an out-of-bounds write and kadmind daemon crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
krb5 > 0-0 (version in image is 1.19.2-150400.3.18.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: prevent A-MSDU attacks in mesh networksThis patch is a mitigation to prevent the A-MSDU spoofing vulnerabilityfor mesh networks. The initial update to the IEEE 802.11 standard, inresponse to the FragAttacks, missed this case (CVE-2025-27558). It canbe considered a variant of CVE-2020-24588 but for mesh networks.This patch tries to detect if a standard MSDU was turned into an A-MSDUby an adversary. This is done by parsing a received A-MSDU as a standardMSDU, calculating the length of the Mesh Control header, and seeing ifthe 6 bytes after this header equal the start of an rfc1042 header. Ifequal, this is a strong indication of an ongoing attack attempt.This defense was tested with mac80211_hwsim against a mesh network thatuses an empty Mesh Address Extension field, i.e., when four addressesare used, and when using a 12-byte Mesh Address Extension field, i.e.,when six addresses are used. Functionality of normal MSDUs and A-MSDUswas also tested, and confirmed working, when using both an empty and12-byte Mesh Address Extension field.It was also tested with mac80211_hwsim that A-MSDU attacks in non-meshnetworks keep being detected and prevented.Note that the vulnerability being patched, and the defense beingimplemented, was also discussed in the following paper and in thefollowing IEEE 802.11 presentation:https://papers.mathyvanhoef.com/wisec2025.pdfhttps://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: ping in iputils before 20250602 allows a denial of service (application error or incorrect data collection) via a crafted ICMP Echo Reply packet, because of a signed 64-bit integer overflow in timestamp multiplication.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
iputils > 0-0 (version in image is 20211215-150400.3.22.1).

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.26.1).

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.26.1).

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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix bsg_done() causing double freeKernel panic observed on system,[5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000[5353358.825194] #PF: supervisor write access in kernel mode[5353358.825195] #PF: error_code(0x0002) - not-present page[5353358.825196] PGD 100006067 P4D 0[5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI[5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el9_5.x86_64 #1[5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025[5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10[5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246[5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000[5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000[5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000[5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090[5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000[5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000[5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0[5353358.825221] PKRU: 55555554[5353358.825222] Call Trace:[5353358.825223] [5353358.825224] ? show_trace_log_lvl+0x1c4/0x2df[5353358.825229] ? show_trace_log_lvl+0x1c4/0x2df[5353358.825232] ? sg_copy_buffer+0xc8/0x110[5353358.825236] ? __die_body.cold+0x8/0xd[5353358.825238] ? page_fault_oops+0x134/0x170[5353358.825242] ? kernelmode_fixup_or_oops+0x84/0x110[5353358.825244] ? exc_page_fault+0xa8/0x150[5353358.825247] ? asm_exc_page_fault+0x22/0x30[5353358.825252] ? memcpy_erms+0x6/0x10[5353358.825253] sg_copy_buffer+0xc8/0x110[5353358.825259] qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx][5353358.825317] qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx]Most routines in qla_bsg.c call bsg_done() only for success cases.However a few invoke it for failure case as well leading to a doublefree. Validate before calling bsg_done().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311 > 0-0 (version in image is 3.11.15-150400.9.85.1).

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

Description: A flaw was found in libssh. The API function `ssh_get_hexa()` is vulnerable to a denial of service when processing zero-length input. This can be exploited remotely by an attacker during GSSAPI (Generic Security Service Application Program Interface) authentication if the server's logging verbosity is set to `SSH_LOG_PACKET (3)` or higher. Successful exploitation could lead to a self-Denial of Service of the per-connection daemon process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libssh-config > 0-0 (version in image is 0.9.8-150400.3.17.1).

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-22992 Severity: Moderate CVSS3 score: 6.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: cap TX credit to local buffer sizeThe virtio transports derives its TX credit directly from peer_buf_alloc,which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value.On the host side this means that the amount of data we are willing toqueue for a connection is scaled by a guest-chosen buffer size, ratherthan the host's own vsock configuration. A malicious guest can advertisea large buffer and read slowly, causing the host to allocate acorrespondingly large amount of sk_buff memory.The same thing would happen in the guest with a malicious host, sincevirtio transports share the same code base.Introduce a small helper, virtio_transport_tx_buf_size(), thatreturns min(peer_buf_alloc, buf_alloc), and use it wherever we consumepeer_buf_alloc.This ensures the effective TX window is bounded by both the peer'sadvertised buffer and our own buf_alloc (already clamped tobuffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peercannot force the other to queue more data than allowed by its ownvsock settings.On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with32 guest vsock connections advertising 2 GiB each and reading slowlydrove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system onlyrecovered after killing the QEMU process. That said, if QEMU memory islimited with cgroups, the maximum memory used will be limited.With this patch applied: Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiBOnly ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guestremains responsive.Compatibility with non-virtio transports: - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer_* values; the remote side cannot enlarge those queues beyond what the local endpoint configured. - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peer_buf_alloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes. - The loopback path reuses virtio_transport_common.c, so it naturally follows the same semantics as the virtio transport.This change is limited to virtio_transport_common.c and thus affectsvirtio-vsock, vhost-vsock, and loopback, bringing them in line with the"remote window intersected with local policy" behaviour that VMCI andHyper-V already effectively have.[Stefano: small adjustments after changing the previous patch][Stefano: tweak the commit message]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctlyThe existing allocation of scatterlists in omap_crypto_copy_sg_lists()was allocating an array of scatterlist pointers, not scatterlist objects,resulting in a 4x too small allocation.Use sizeof(*new_sg) to get the correct object size.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: fix UAF in xchk_btree_check_block_ownerWe cannot dereference bs->cur when trying to determine if bs->curaliases bs->sc->sa.{bno,rmap}_cur after the latter has been freed.Fix this by sampling before type before any freeing could happen.The correct temporal ordering was broken when we removed xfs_btnum_t.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: add xmit recursion limit to tunnel xmit functionsTunnel xmit functions (iptunnel_xmit, ip6tunnel_xmit) lack their ownrecursion limit. When a bond device in broadcast mode has GRE tapinterfaces as slaves, and those GRE tunnels route back through thebond, multicast/broadcast traffic triggers infinite recursion betweenbond_xmit_broadcast() and ip_tunnel_xmit()/ip6_tnl_xmit(), causingkernel stack overflow.The existing XMIT_RECURSION_LIMIT (8) in the no-qdisc path is notsufficient because tunnel recursion involves route lookups and full IPoutput, consuming much more stack per level. Use a lower limit of 4(IP_TUNNEL_RECURSION_LIMIT) to prevent overflow.Add recursion detection using dev_xmit_recursion helpers directly iniptunnel_xmit() and ip6tunnel_xmit() to cover all IPv4/IPv6 tunnelpaths including UDP encapsulated tunnels (VXLAN, Geneve, etc.).Move dev_xmit_recursion helpers from net/core/dev.h to public headerinclude/linux/netdevice.h so they can be used by tunnel code. BUG: KASAN: stack-out-of-bounds in blake2s.constprop.0+0xe7/0x160 Write of size 32 at addr ffff88810033fed0 by task kworker/0:1/11 Workqueue: mld mld_ifc_work Call Trace: __build_flow_key.constprop.0 (net/ipv4/route.c:515) ip_rt_update_pmtu (net/ipv4/route.c:1073) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:84) ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) ip_finish_output2 (net/ipv4/ip_output.c:237) ip_output (net/ipv4/ip_output.c:438) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) ip_finish_output2 (net/ipv4/ip_output.c:237) ip_output (net/ipv4/ip_output.c:438) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86) ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) mld_sendpack mld_ifc_work process_one_work worker_thread

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix NULL pointer dereference in mesh_rx_csa_frame()In mesh_rx_csa_frame(), elems->mesh_chansw_params_ie is dereferencedat lines 1638 and 1642 without a prior NULL check: ifmsh->chsw_ttl = elems->mesh_chansw_params_ie->mesh_ttl; ... pre_value = le16_to_cpu(elems->mesh_chansw_params_ie->mesh_pre_value);The mesh_matches_local() check above only validates the Mesh ID,Mesh Configuration, and Supported Rates IEs. It does not verify thepresence of the Mesh Channel Switch Parameters IE (element ID 118).When a received CSA action frame omits that IE, ieee802_11_parse_elems()leaves elems->mesh_chansw_params_ie as NULL, and the unconditionaldereference causes a kernel NULL pointer dereference.A remote mesh peer with an established peer link (PLINK_ESTAB) cantrigger this by sending a crafted SPECTRUM_MGMT/CHL_SWITCH action framethat includes a matching Mesh ID and Mesh Configuration IE but omits theMesh Channel Switch Parameters IE. No authentication beyond the defaultopen mesh peering is required.Crash confirmed on kernel 6.17.0-5-generic via mac80211_hwsim: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:ieee80211_mesh_rx_queued_mgmt+0x143/0x2a0 [mac80211] CR2: 0000000000000000Fix by adding a NULL check for mesh_chansw_params_ie aftermesh_matches_local() returns, consistent with how other optional IEsare guarded throughout the mesh code.The bug has been present since v3.13 (released 2014-01-19).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQCurrently the code attempts to accept requests regardless of thecommand identifier which may cause multiple requests to be markedas pending (FLAG_DEFER_SETUP) which can cause more thanL2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defercausing an overflow.The spec is quite clear that the same identifier shall not be used onsubsequent requests:'Within each signaling channel a different Identifier shall be usedfor each successive request or indication.'https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355dSo this attempts to check if there are any channels pending with thesame identifier and rejects if any are found.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix NULL deref in mesh_matches_local()mesh_matches_local() unconditionally dereferences ie->mesh_config tocompare mesh configuration parameters. When called frommesh_rx_csa_frame(), the parsed action-frame elements may not contain aMesh Configuration IE, leaving ie->mesh_config NULL and triggering akernel NULL pointer dereference.The other two callers are already safe: - ieee80211_mesh_rx_bcn_presp() checks !elems->mesh_config before calling mesh_matches_local() - mesh_plink_get_event() is only reached through mesh_process_plink_frame(), which checks !elems->mesh_config, toomesh_rx_csa_frame() is the only caller that passes raw parsed elementsto mesh_matches_local() without guarding mesh_config. An adjacentattacker can exploit this by sending a crafted CSA action frame thatincludes a valid Mesh ID IE but omits the Mesh Configuration IE,crashing the kernel.The captured crash log:Oops: general protection fault, probably for non-canonical address ...KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]Workqueue: events_unbound cfg80211_wiphy_work[...]Call Trace: ? __pfx_mesh_matches_local (net/mac80211/mesh.c:65) ieee80211_mesh_rx_queued_mgmt (net/mac80211/mesh.c:1686) [...] ieee80211_iface_work (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802) [...] cfg80211_wiphy_work (net/wireless/core.c:426) process_one_work (net/kernel/workqueue.c:3280) ? assign_work (net/kernel/workqueue.c:1219) worker_thread (net/kernel/workqueue.c:3352) ? __pfx_worker_thread (net/kernel/workqueue.c:3385) kthread (net/kernel/kthread.c:436) [...] ret_from_fork_asm (net/arch/x86/entry/entry_64.S:255) This patch adds a NULL check for ie->mesh_config at the top ofmesh_matches_local() to return false early when the Mesh ConfigurationIE is absent.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTEWhen installing an emulated MMIO SPTE, do so *after* dropping/zapping theexisting SPTE (if it's shadow-present). While commit a54aa15c6bda3 wasright about it being impossible to convert a shadow-present SPTE to anMMIO SPTE due to a _guest_ write, it failed to account for writes to guestmemory that are outside the scope of KVM.E.g. if host userspace modifies a shadowed gPTE to switch from a memslotto emulted MMIO and then the guest hits a relevant page fault, KVM willinstall the MMIO SPTE without first zapping the shadow-present SPTE. ------------[ cut here ]------------ is_shadow_present_pte(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm] Call Trace: mmu_set_spte+0x237/0x440 [kvm] ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47fa3f ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: add NULL checks for idev in SRv6 paths__in6_dev_get() can return NULL when the device has no IPv6 configuration(e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).Add NULL checks for idev returned by __in6_dev_get() in bothseg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULLpointer dereferences.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.26.1).

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.37.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loopl2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTEDstate to support L2CAP reconfiguration (e.g. MTU changes). However,since both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set fromthe initial configuration, the reconfiguration path falls through tol2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, andretrans_list without freeing the previous allocations and setschan->sdu to NULL without freeing the existing skb. This leaks allpreviously allocated ERTM resources.Additionally, l2cap_parse_conf_req() does not validate the minimumvalue of remote_mps derived from the RFC max_pdu_size option. A zerovalue propagates to l2cap_segment_sdu() where pdu_len becomes zero,causing the while loop to never terminate since len is neverdecremented, exhausting all available memory.Fix the double-init by skipping l2cap_ertm_init() andl2cap_chan_ready() when the channel is already in BT_CONNECTED state,while still allowing the reconfiguration parameters to be updatedthrough l2cap_parse_conf_req(). Also add a pdu_len zero check inl2cap_segment_sdu() as a safeguard.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: reject oversized global TT response buffersbatadv_tt_prepare_tvlv_global_data() builds the allocation length for aglobal TT response in 16-bit temporaries. When a remote originatoradvertises a large enough global TT, the TT payload length plus the VLANheader offset can exceed 65535 and wrap before kmalloc().The full-table response path still uses the original TT payload length whenit fills tt_change, so the wrapped allocation is too small andbatadv_tt_prepare_tvlv_global_data() writes past the end of the heap objectbefore the later packet-size check runs.Fix this by rejecting TT responses whose TVLV value length cannot fit inthe 16-bit TVLV payload length field.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_csum: validate nested VLAN headerstcf_csum_act() walks nested VLAN headers directly from skb->data when anskb still carries in-payload VLAN tags. The current code readsvlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes withoutfirst ensuring that the full VLAN header is present in the linear area.If only part of an inner VLAN header is linearized, accessingh_vlan_encapsulated_proto reads past the linear area, and the followingskb_pull(VLAN_HLEN) may violate skb invariants.Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing andpulling each nested VLAN header. If the header still is not fullyavailable, drop the packet through the existing error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
openssh < 8.4p1-150300.3.65.1 (version in image is 8.4p1-150300.3.60.1).

CVE-2026-34978 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.16 and prior, the RSS notifier allows .. path traversal in notify-recipient-uri (e.g., rss:///../job.cache), letting a remote IPP client write RSS XML bytes outside CacheDir/rss (anywhere that is lp-writable). In particular, because CacheDir is group-writable by default (typically root:lp and mode 0770), the notifier (running as lp) can replace root-managed state files via temp-file + rename(). This PoC clobbers CacheDir/job.cache with RSS XML, and after restarting cupsd the scheduler fails to parse the job cache and previously queued jobs disappear. At time of publication, there are no publicly available patches.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
cups-config > 0-0 (version in image is 2.2.7-150000.3.86.1).

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

Description: spdystream is a Go library for multiplexing streams over SPDY connections. In versions 0.5.0 and below, the SPDY/3 frame parser does not validate attacker-controlled counts and lengths before allocating memory. Three allocation paths are affected: the SETTINGS frame entry count, the header count in parseHeaderValueBlock, and individual header field sizes - all read as 32-bit integers and used directly as allocation sizes with no bounds checking. Because SPDY header blocks are zlib-compressed, a small on-the-wire payload can decompress into large attacker-controlled values. A remote peer that can send SPDY frames to a service using spdystream can exhaust process memory and cause an out-of-memory crash with a single crafted control frame. This issue has been fixed in version 0.5.1.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
containerd > 0-0 (version in image is 1.7.29-150000.132.1).

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

Description: A path traversal in handling the "path" component of .repo files processed by libzypp before 17.38.13 in the 17.x series, or before 16.22.19 could be used by attackers to fill directories on the system outside of the zypp cache with content.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libsolv-tools < 0.7.39-150400.3.46.1 (version in image is 0.7.34-150400.3.41.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: cap upcall PID array size and pre-size vport repliesThe vport netlink reply helpers allocate a fixed-size skb withnlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PIDarray via ovs_vport_get_upcall_portids(). Sinceovs_vport_set_upcall_portids() accepts any non-zero multiple ofsizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PIDarray large enough to overflow the reply buffer, causing nla_put() tofail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems withunprivileged user namespaces enabled (e.g., Ubuntu default), this isreachable via unshare -Urn since OVS vport mutation operations useGENL_UNS_ADMIN_PERM. kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Kernel panic - not syncing: Fatal exceptionReject attempts to set more PIDs than nr_cpu_ids inovs_vport_set_upcall_portids(), and pre-compute the worst-case replysize in ovs_vport_cmd_msg_size() based on that bound, similar to theexisting ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap alreadyused by the per-CPU dispatch configuration on the datapath side(ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so thetwo sides stay consistent.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:slip: reject VJ receive packets on instances with no rstate arrayslhc_init() accepts rslots == 0 as a valid configuration, with thedocumented meaning of 'no receive compression'. In that case theallocation loop in slhc_init() is skipped, so comp->rstate staysNULL and comp->rslot_limit stays 0 (from the kzalloc of structslcompress).The receive helpers do not defend against that configuration.slhc_uncompress() dereferences comp->rstate[x] when the VJ headercarries an explicit connection ID, and slhc_remember() later assignscs = &comp->rstate[...] after only comparing the packet's slot numberto comp->rslot_limit. Because rslot_limit is 0, slot 0 passes therange check, and the code dereferences a NULL rstate.The configuration is reachable in-tree through PPP. PPPIOCSMAXCIDstores its argument in a signed int, and (val >> 16) uses arithmeticshift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because/dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole pathis reachable from an unprivileged user namespace. Once the malformedVJ state is installed, any inbound VJ-compressed or VJ-uncompressedframe that selects slot 0 crashes the kernel in softirq context: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519) Call Trace: ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466) ppp_input (drivers/net/ppp/ppp_generic.c:2359) ppp_async_process (drivers/net/ppp/ppp_async.c:492) tasklet_action_common (kernel/softirq.c:926) handle_softirqs (kernel/softirq.c:623) run_ksoftirqd (kernel/softirq.c:1055) smpboot_thread_fn (kernel/smpboot.c:160) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) Reject the receive side on such instances instead of touching rstate.slhc_uncompress() falls through to its existing 'bad' label, whichbumps sls_i_error and enters the toss state. slhc_remember() mirrorsthat with an explicit sls_i_error increment followed by slhc_toss();the sls_i_runt counter is not used here because a missing rstate isan internal configuration state, not a runt packet.The transmit path is unaffected: the only in-tree caller that picksrslots from userspace (ppp_generic.c) still supplies tslots >= 1, andslip.c always calls slhc_init(16, 16), so comp->tstate remains validand slhc_compress() continues to work.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: arp_tables: fix IEEE1394 ARP payload parsingWeiming Shi says:"arp_packet_match() unconditionally parses the ARP payload assuming twohardware addresses are present (source and target). However,IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware addressfield, and arp_hdr_len() already accounts for this by returning ashorter length for ARPHRD_IEEE1394 devices.As a result, on IEEE1394 interfaces arp_packet_match() advances past anonexistent target hardware address and reads the wrong bytes for boththe target device address comparison and the target IP address. Thiscauses arptables rules to match against garbage data, leading toincorrect filtering decisions: packets that should be accepted may bedropped and vice versa.The ARP stack in net/ipv4/arp.c (arp_create and arp_process) alreadyhandles this correctly by skipping the target hardware address forARPHRD_IEEE1394. Apply the same pattern to arp_packet_match()."Mangle the original patch to always return 0 (no match) in case usermatches on the target hardware address which is never present inIEEE1394.Note that this returns 0 (no match) for either normal and inverse matchbecause matching in the target hardware address in ARPHRD_IEEE1394 hasnever been supported by arptables. This is intentional, matching on thetarget hardware address should never evaluate true for ARPHRD_IEEE1394.Moreover, adjust arpt_mangle to drop the packet too as AI suggests:In arpt_mangle, the logic assumes a standard ARP layout. BecauseIEEE1394 (FireWire) omits the target hardware address, the linearpointer arithmetic miscalculates the offset for the target IP address.This causes mangling operations to write to the wrong location, leadingto packet corruption. To ensure safety, this patch drops packets(NF_DROP) when mangling is requested for these fields on IEEE1394devices, as the current implementation cannot correctly map the FireWireARP payload.This omits both mangling target hardware and IP address. Even if IPaddress mangling should be possible in IEEE1394, this would requireto adjust arpt_mangle offset calculation, which has never beensupported.Based on patch from Weiming Shi .

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: auth_gss: fix memory leaks in XDR decoding error pathsThe gssx_dec_ctx(), gssx_dec_status(), and gssx_dec_name()functions allocate memory via gssx_dec_buffer(), which callskmemdup(). When a subsequent decode operation fails, thesefunctions return immediately without freeing previouslyallocated buffers, causing memory leaks.The leak in gssx_dec_ctx() is particularly relevant becausethe caller (gssp_accept_sec_context_upcall) initializes severalbuffer length fields to non-zero values, resulting in memoryallocation: struct gssx_ctx rctxh = { .exported_context_token.len = GSSX_max_output_handle_sz, .mech.len = GSS_OID_MAX_LEN, .src_name.display_name.len = GSSX_max_princ_sz, .targ_name.display_name.len = GSSX_max_princ_sz };If, for example, gssx_dec_name() succeeds for src_name butfails for targ_name, the memory allocated forexported_context_token, mech, and src_name.display_nameremains unreferenced and cannot be reclaimed.Add error handling with goto-based cleanup to free anypreviously allocated buffers before returning an error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:xen-netback: reject zero-queue configuration from guestA malicious or buggy Xen guest can write "0" to the xenbus key"multi-queue-num-queues". The connect() function in the backend onlyvalidates the upper bound (requested_num_queues > xenvif_max_queues)but not zero, allowing requested_num_queues=0 to reachvzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggersWARN_ON_ONCE(!size) in __vmalloc_node_range().On systems with panic_on_warn=1, this allows a guest-to-host denialof service.The Xen network interface specification requiresthe queue count to be "greater than zero".Add a zero check to match the validation already presentin xen-blkback, which has included thisguard since its multi-queue support was added.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply()If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for bothprotocol and result, this is currently not treated as an error. In caseof ac->negotiating == true and ac->protocol > 0, this leads to settingac->protocol = 0 and ac->ops = NULL. Thereafter, the check forac->protocol != protocol returns false, and init_protocol() is notcalled. Subsequently, ac->ops->handle_reply() is called, which leads toa null pointer dereference, because ac->ops is still NULL.This patch changes the check for ac->protocol != protocol to!ac->protocol, as this also includes the case when the protocol was setto zero in the message. This causes the message to be treated ascontaining a bad auth protocol.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evthci_le_create_big_complete_evt() iterates over BT_BOUND connections fora BIG handle using a while loop, accessing ev->bis_handle[i++] on eachiteration. However, there is no check that i stays within ev->num_bisbefore the array access.When a controller sends a LE_Create_BIG_Complete event with fewerbis_handle entries than there are BT_BOUND connections for that BIG,or with num_bis=0, the loop reads beyond the valid bis_handle[] flexarray into adjacent heap memory. Since the out-of-bounds valuestypically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle()rejects them and the connection remains in BT_BOUND state. The sameconnection is then found again by hci_conn_hash_lookup_big_state(),creating an infinite loop with hci_dev_lock held.Fix this by terminating the BIG if in case not all BIS could be setupproperly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix uninit-value by validating catalog record sizeSyzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). Theroot cause is that hfs_brec_read() doesn't validate that the on-diskrecord size matches the expected size for the record type being read.When mounting a corrupted filesystem, hfs_brec_read() may read less datathan expected. For example, when reading a catalog thread record, thedebug output showed: HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26 HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ!hfs_brec_read() only validates that entrylength is not greater than thebuffer size, but doesn't check if it's less than expected. It successfullyreads 26 bytes into a 520-byte structure and returns success, leaving 494bytes uninitialized.This uninitialized data in tmp.thread.nodeName then gets copied byhfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggeringthe KMSAN warning when the uninitialized bytes are used as array indicesin case_fold().Fix by introducing hfsplus_brec_read_cat() wrapper that:1. Calls hfs_brec_read() to read the data2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length)3. Returns -EIO if size doesn't match expectedFor thread records, check against HFSPLUS_MIN_THREAD_SZ before readingnodeName.length to avoid reading uninitialized data at call sites thatdon't zero-initialize the entry structure.Also initialize the tmp variable in hfsplus_find_cat() as defensiveprogramming to ensure no uninitialized data even if validation isbypassed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: bla: put backbone reference on failed claim hash insertWhen batadv_bla_add_claim() fails to insert a new claim into the hash, itleaked a reference to the backbone_gw for which the claim was intended.Call batadv_backbone_gw_put() on the error path to release the referenceand avoid leaking the backbone_gw object.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix rlimit for posix cpu timersPosix cpu timers requires an additional step beyond setting the rlimit.Refactor the code so its clear when what code is setting thelimit and conditionally update the posix cpu timers when appropriate.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: handle rbtree insertion error in decode_choose_args()A message of type CEPH_MSG_OSD_MAP contains an OSD map that itselfcontains a CRUSH map. The received CRUSH map may optionally containchoose_args that get decoded in decode_choose_args(). In this function,num_choose_arg_maps is read from the message, and a corresponding numberof crush_choose_arg_maps gets decoded afterwards. Eachcrush_choose_arg_map has a choose_args_index, which serves as the keywhen inserting it into the choose_args rbtree of the decoded crush_map.If a (potentially corrupted) message contains two crush_choose_arg_mapswith the same index, the assertion in insert_choose_arg_map() triggers akernel BUG when trying to insert the second crush_choose_arg_map.This patch fixes the issue by switching to the non-asserting rbtreeinsertion function and rejecting the message if the insertion fails.[ idryomov: changelog ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb/client: fix possible infinite loop and oob read in symlink_data()On 32-bit architectures, the infinite loop is as follows: len = p->ErrorDataLength == 0xfffffff8 u8 *next = p->ErrorContextData + len next == pOn 32-bit architectures, the out-of-bounds read is as follows: len = p->ErrorDataLength == 0xfffffff0 u8 *next = p->ErrorContextData + len next == (u8 *)p - 8

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: Fix use-after-free when processing MLD queriesWhen processing an MLD query, a pointer to the multicast group addressis retrieved when initially parsing the packet. This pointer is laterdereferenced without being reloaded despite the fact that the skb headermight have been reallocated following the pskb_may_pull() calls, leadingto a use-after-free [1].Fix by copying the multicast group address when the packet is initiallyparsed.[1]BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512)Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118Workqueue: mld mld_query_workCall Trace:dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)print_address_description.constprop.0 (mm/kasan/report.c:378)print_report (mm/kasan/report.c:482)kasan_report (mm/kasan/report.c:595)__mld_query_work (net/ipv6/mcast.c:1512)mld_query_work (net/ipv6/mcast.c:1563)process_one_work (kernel/workqueue.c:3314)worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)kthread (kernel/kthread.c:436)ret_from_fork (arch/x86/kernel/process.c:158)ret_from_fork_asm (arch/x86/entry/entry_64.S:245)[...]Freed by task 118:kasan_save_stack (mm/kasan/common.c:57)kasan_save_track (mm/kasan/common.c:78)kasan_save_free_info (mm/kasan/generic.c:584)__kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285)kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566)pskb_expand_head (net/core/skbuff.c:2335)__pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4))__mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1))mld_query_work (net/ipv6/mcast.c:1563)process_one_work (kernel/workqueue.c:3314)worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)kthread (kernel/kthread.c:436)ret_from_fork (arch/x86/kernel/process.c:158)ret_from_fork_asm (arch/x86/entry/entry_64.S:245)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: A flaw was found in libxml2. This vulnerability occurs when the library processes a specially crafted XML Schema Definition (XSD) validated document that includes an internal entity reference. An attacker could exploit this by providing a malicious document, leading to a type confusion error that causes the application to crash. This results in a denial of service (DoS), making the affected system or application unavailable.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.55.1).

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

Description: A flaw was found in libsolv. This heap buffer overflow vulnerability occurs when a victim processes a specially crafted `.solv` file containing negative size values in the `repo_add_solv` function. This leads to an undersized memory allocation and a subsequent out-of-bounds write. An attacker could exploit this to cause a denial of service (DoS).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libsolv-tools < 0.7.39-150400.3.46.1 (version in image is 0.7.34-150400.3.41.1).

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

Description: A flaw was found in libsolv. This stack-based buffer overflow vulnerability occurs in libsolv's Debian metadata parser when processing specially crafted Debian repository metadata. An attacker could exploit this by providing malicious SHA384 or SHA512 checksum tags, leading to memory corruption and a denial of service (DoS) in the affected system.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libsolv-tools < 0.7.39-150400.3.46.1 (version in image is 0.7.34-150400.3.41.1).

CVE-2021-47634 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctlHulk Robot reported a KASAN report about use-after-free: ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160 Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385 [...] Call Trace: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi] Allocated by task 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi] Freed by task 1385: cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ==================================================================The lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock heldby ubi_cdev_ioctl is ubi->device_mutex. Therefore, the two locks can beconcurrent.ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach.ubi_detach is bug-free because it uses reference counting to preventconcurrency. However, uif_init and uif_close in ubi_attach may race withubi_cdev_ioctl.uif_init will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3_______________________|________________________|______________________ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs exist kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume cdev_del // double free cdev_device_delAnd uif_close will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3_______________________|________________________|______________________ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume // double freeThe cause of this problem is that commit 714fb87e8bc0 make device"available" before it becomes accessible via sysfs. Therefore, weroll back the modification. We will fix the race condition betweenubi device creation and udev by removing ubi_get_device invol_attribute_show and dev_attribute_show.This avoids accessinguninitialized ubi_devices[ubi_num].ubi_get_device is used to prevent devices from being deleted duringsysfs execution. However, now kernfs ensures that devices will notbe deleted before all reference counting are released.The key process is shown in the following stack.device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50616 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: Use different devices for resource allocation and DT lookupFollowing by the below discussion, there's the potential UAF issuebetween regulator and mfd.https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/From the analysis of YingliangCPU A |CPU Bmt6370_probe() | devm_mfd_add_devices() | |mt6370_regulator_probe() | regulator_register() | //allocate init_data and add it to devres | regulator_of_get_init_data()i2c_unregister_device() | device_del() | devres_release_all() | // init_data is freed | release_nodes() | | // using init_data causes UAF | regulator_register()It's common to use mfd core to create child device for the regulator.In order to do the DT lookup for init data, the child that registeredthe regulator would pass its parent as the parameter. And this causesinit data resource allocated to its parent, not itself. The issue happenwhen parent device is going to release and regulator core is still doingsome operation of init data constraint for the regulator of child device.To fix it, this patch expand 'regulator_register' API to use thedifferent devices for init data allocation and DT lookup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53285 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add bounds checking in get_max_inline_xattr_value_size()Normally the extended attributes in the inode body would have beenchecked when the inode is first opened, but if someone is writing tothe block device while the file system is mounted, it's possible forthe inode table to get corrupted. Add bounds checking to avoidreading beyond the end of allocated memory if this happens.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54310 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: message: mptlan: Fix use after free bug in mptlan_remove() due to race conditionmptlan_probe() calls mpt_register_lan_device() which initializes the&priv->post_buckets_task workqueue. A call tompt_lan_wake_post_buckets_task() will subsequently start the work.During driver unload in mptlan_remove() the following race may occur:CPU0 CPU1 |mpt_lan_post_receive_buckets_work()mptlan_remove() | free_netdev() | kfree(dev); | | | dev->mtu | //useFix this by finishing the work prior to cleaning up in mptlan_remove().[mkp: we really should remove mptlan instead of attempting to fix it]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-7256 Severity: Moderate CVSS3 score: 6.4

Description: In affected libpcap versions during the setup of a remote packet capture the internal function sock_initaddress() calls getaddrinfo() and possibly freeaddrinfo(), but does not clearly indicate to the caller function whether freeaddrinfo() still remains to be called after the function returns. This makes it possible in some scenarios that both the function and its caller call freeaddrinfo() for the same allocated memory block. A similar problem was reported in Apple libpcap, to which Apple assigned CVE-2023-40400.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libpcap1 > 0-0 (version in image is 1.10.1-150400.3.9.1).

CVE-2024-26875 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:media: pvrusb2: fix uaf in pvr2_context_set_notify[Syzbot reported]BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024Workqueue: usb_hub_wq hub_eventCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272Freed by task 906:kasan_save_stack+0x33/0x50 mm/kasan/common.c:47kasan_save_track+0x14/0x30 mm/kasan/common.c:68kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640poison_slab_object mm/kasan/common.c:241 [inline]__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257kasan_slab_free include/linux/kasan.h:184 [inline]slab_free_hook mm/slub.c:2121 [inline]slab_free mm/slub.c:4299 [inline]kfree+0x105/0x340 mm/slub.c:4409pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158[Analyze]Task A set disconnect_flag = !0, which resulted in Task B's condition being metand releasing mp, leading to this issue.[Fix]Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()to avoid this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26996 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport errorWhen ncm function is working and then stop usb0 interface for link down,eth_stop() is called. At this piont, accidentally if usb transport errorshould happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled.After that, ncm_disable() is called to disable for ncm unbindbut gether_disconnect() is never called since 'in_ep' is not enabled.As the result, ncm object is released in ncm unbindbut 'dev->port_usb' associated to 'ncm->port' is not NULL.And when ncm bind again to recover netdev, ncm object is reallocatedbut usb0 interface is already associated to previous released ncm object.Therefore, once usb0 interface is up and eth_start_xmit() is called,released ncm object is dereferrenced and it might cause use-after-free memory.[function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm[function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014fThis patch addresses the issue by checking if 'ncm->netdev' is not NULL atncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'.It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnectrather than check 'ncm->port.in_ep->enabled' since it might not be enabledbut the gether connection might be established.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36012 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: msft: fix slab-use-after-free in msft_do_close()Tying the msft->data lifetime to hdev by freeing it inhci_release_dev() to fix the following case:[use]msft_do_close() msft = hdev->msft_data; if (!msft) ...(1) <- passed. return; mutex_lock(&msft->filter_lock); ...(4) <- used after freed.[free]msft_unregister() msft = hdev->msft_data; hdev->msft_data = NULL; ...(2) kfree(msft); ...(3) <- msft is freed.==================================================================BUG: KASAN: slab-use-after-free in __mutex_lock_commonkernel/locking/mutex.c:587 [inline]BUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30kernel/locking/mutex.c:752Read of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38577 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflowThere is a possibility of buffer overflow inshow_rcu_tasks_trace_gp_kthread() if counters, passedto sprintf() are huge. Counter numbers, needed for thisare unrealistically high, but buffer overflow is stillpossible.Use snprintf() with buffer size instead of sprintf().Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40927 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:xhci: Handle TD clearing for multiple streams caseWhen multiple streams are in use, multiple TDs might be in flight whenan endpoint is stopped. We need to issue a Set TR Dequeue Pointer foreach, to ensure everything is reset properly and the caches cleared.Change the logic so that any N>1 TDs found active for different streamsare deferred until after the first one is processed, callingxhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() toqueue another command until we are done with all of them. Also changethe error/"should never happen" paths to ensure we at least clear anyaffected TDs, even if we can't issue a command to clear the hardwarecache, and complain loudly with an xhci_warn() if this ever happens.This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correctassumptions about number of rings per endpoint.") early on in the XHCIdriver's life, when stream support was first added.It was then identified but not fixed nor made into a warning in commit674f8438c121 ("xhci: split handling halted endpoints into two steps"),which added a FIXME comment for the problem case (without materiallychanging the behavior as far as I can tell, though the new logic madethe problem more obvious).Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back somecached cancelled URBs."), it was acknowledged again.[Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cachedcancelled URBs.") was a targeted regression fix to the previously mentionedpatch. Users reported issues with usb stuck after unmounting/disconnectingUAS devices. This rolled back the TD clearing of multiple streams to itsoriginal state.]Apparently the commit author was aware of the problem (yet still choseto submit it): It was still mentioned as a FIXME, an xhci_dbg() wasadded to log the problem condition, and the remaining issue was mentionedin the commit description. The choice of making the log type xhci_dbg()for what is, at this point, a completely unhandled and known brokencondition is puzzling and unfortunate, as it guarantees that no actualusers would see the log in production, thereby making it nighundebuggable (indeed, even if you turn on DEBUG, the message doesn'treally hint at there being a problem at all).It took me *months* of random xHC crashes to finally find a reliablerepro and be able to do a deep dive debug session, which could all havebeen avoided had this unhandled, broken condition been actually reportedwith a warning, as it should have been as a bug intentionally left inunfixed (never mind that it shouldn't have been left in at all).> Another fix to solve clearing the caches of all stream rings with> cancelled TDs is needed, but not as urgent.3 years after that statement and 14 years after the original bug wasintroduced, I think it's finally time to fix it. And maybe next timelet's not leave bugs unfixed (that are actually worse than the originalbug), and let's actually get people to review kernel commits please.Fixes xHC crashes and IOMMU faults with UAS devices when handlingerrors/faults. Easiest repro is to use `hdparm` to mark an early sector(e.g. 1024) on a disk as bad, then `cat /dev/sdX > /dev/null` in a loop.At least in the case of JMicron controllers, the read errors end uphaving to cancel two TDs (for two queued requests to different streams)and the one that didn't get cleared properly ends up faulting the xHCentirely when it tries to access DMA pages that have since been unmapped,referred to by the stale TDs. This normally happens quickly (after twoor three loops). After this fix, I left the `cat` in a loop runningovernight and experienced no xHC failures, with all read errorsrecovered properly. Repro'd and tested on an Apple M1 Mac Mini(dwc3 host).On systems without an IOMMU, this bug would instead silently corruptfreed memory, making this a---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41040 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Fix UAF when resolving a clashKASAN reports the following UAF: BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct] Read of size 1 at addr ffff888c07603600 by task handler130/6469 Call Trace: dump_stack_lvl+0x48/0x70 print_address_description.constprop.0+0x33/0x3d0 print_report+0xc0/0x2b0 kasan_report+0xd0/0x120 __asan_load1+0x6c/0x80 tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct] tcf_ct_act+0x886/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 __irq_exit_rcu+0x82/0xc0 irq_exit_rcu+0xe/0x20 common_interrupt+0xa1/0xb0 asm_common_interrupt+0x27/0x40 Allocated by task 6469: kasan_save_stack+0x38/0x70 kasan_set_track+0x25/0x40 kasan_save_alloc_info+0x1e/0x40 __kasan_krealloc+0x133/0x190 krealloc+0xaa/0x130 nf_ct_ext_add+0xed/0x230 [nf_conntrack] tcf_ct_act+0x1095/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 Freed by task 6469: kasan_save_stack+0x38/0x70 kasan_set_track+0x25/0x40 kasan_save_free_info+0x2b/0x60 ____kasan_slab_free+0x180/0x1f0 __kasan_slab_free+0x12/0x30 slab_free_freelist_hook+0xd2/0x1a0 __kmem_cache_free+0x1a2/0x2f0 kfree+0x78/0x120 nf_conntrack_free+0x74/0x130 [nf_conntrack] nf_ct_destroy+0xb2/0x140 [nf_conntrack] __nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack] nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack] __nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack] tcf_ct_act+0x12ad/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491The ct may be dropped if a clash has been resolved but is still passed tothe tcf_ct_flow_table_process_conn function for further usage. This issuecan be fixed by retrieving ct from skb again after confirming conntrack.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41070 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().It looks up `stt` from tablefd, but then continues to use it after doingfdput() on the returned fd. After the fdput() the tablefd is free to beclosed by another thread. The close calls kvm_spapr_tce_release() andthen release_spapr_tce_table() (via call_rcu()) which frees `stt`.Although there are calls to rcu_read_lock() inkvm_spapr_tce_attach_iommu_group() they are not sufficient to preventthe UAF, because `stt` is used outside the locked regions.With an artifcial delay after the fdput() and a userspace program whichtriggers the race, KASAN detects the UAF: BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505 CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1 Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Call Trace: dump_stack_lvl+0xb4/0x108 (unreliable) print_report+0x2b4/0x6ec kasan_report+0x118/0x2b0 __asan_load4+0xb8/0xd0 kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] kvm_vfio_set_attr+0x524/0xac0 [kvm] kvm_device_ioctl+0x144/0x240 [kvm] sys_ioctl+0x62c/0x1810 system_call_exception+0x190/0x440 system_call_vectored_common+0x15c/0x2ec ... Freed by task 0: ... kfree+0xec/0x3e0 release_spapr_tce_table+0xd4/0x11c [kvm] rcu_core+0x568/0x16a0 handle_softirqs+0x23c/0x920 do_softirq_own_stack+0x6c/0x90 do_softirq_own_stack+0x58/0x90 __irq_exit_rcu+0x218/0x2d0 irq_exit+0x30/0x80 arch_local_irq_restore+0x128/0x230 arch_local_irq_enable+0x1c/0x30 cpuidle_enter_state+0x134/0x5cc cpuidle_enter+0x6c/0xb0 call_cpuidle+0x7c/0x100 do_idle+0x394/0x410 cpu_startup_entry+0x60/0x70 start_secondary+0x3fc/0x410 start_secondary_prolog+0x10/0x14Fix it by delaying the fdput() until `stt` is no longer in use, whichis effectively the entire function. To keep the patch minimal add a callto fdput() at each of the existing return paths. Future work can convertthe function to goto or __cleanup style cleanup.With the fix in place the test case no longer triggers the UAF.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41073 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:nvme: avoid double free special payloadIf a discard request needs to be retried, and that retry may fail beforea new special payload is added, a double free will result. Clear theRQF_SPECIAL_LOAD when the request is cleaned.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43900 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:media: xc2028: avoid use-after-free in load_firmware_cb()syzkaller reported use-after-free in load_firmware_cb() [1].The reason is because the module allocated a struct tuner in tuner_probe(),and then the module initialization failed, the struct tuner was released.A worker which created during module initialization accesses this structtuner later, it caused use-after-free.The process is as follows:task-6504 worker_threadtuner_probe <= alloc dvb_frontend [2]...request_firmware_nowait <= create a worker...tuner_remove <= free dvb_frontend... request_firmware_work_func <= the firmware is ready load_firmware_cb <= but now the dvb_frontend has been freedTo fix the issue, check the dvd_frontend in load_firmware_cb(), if it isnull, report a warning and just return.[1]: ================================================================== BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0 Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504 Call trace: load_firmware_cb+0x1310/0x17a0 request_firmware_work_func+0x128/0x220 process_one_work+0x770/0x1824 worker_thread+0x488/0xea0 kthread+0x300/0x430 ret_from_fork+0x10/0x20 Allocated by task 6504: kzalloc tuner_probe+0xb0/0x1430 i2c_device_probe+0x92c/0xaf0 really_probe+0x678/0xcd0 driver_probe_device+0x280/0x370 __device_attach_driver+0x220/0x330 bus_for_each_drv+0x134/0x1c0 __device_attach+0x1f4/0x410 device_initial_probe+0x20/0x30 bus_probe_device+0x184/0x200 device_add+0x924/0x12c0 device_register+0x24/0x30 i2c_new_device+0x4e0/0xc44 v4l2_i2c_new_subdev_board+0xbc/0x290 v4l2_i2c_new_subdev+0xc8/0x104 em28xx_v4l2_init+0x1dd0/0x3770 Freed by task 6504: kfree+0x238/0x4e4 tuner_remove+0x144/0x1c0 i2c_device_remove+0xc8/0x290 __device_release_driver+0x314/0x5fc device_release_driver+0x30/0x44 bus_remove_device+0x244/0x490 device_del+0x350/0x900 device_unregister+0x28/0xd0 i2c_unregister_device+0x174/0x1d0 v4l2_device_unregister+0x224/0x380 em28xx_v4l2_init+0x1d90/0x3770 The buggy address belongs to the object at ffff8000d7ca2000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 776 bytes inside of 2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800) The buggy address belongs to the page: page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0 flags: 0x7ff800000000100(slab) raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================[2] Actually, it is allocated for struct tuner, and dvb_frontend is inside.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46673 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aacraid: Fix double-free on probe failureaac_probe_one() calls hardware-specific init functions through theaac_driver_ident::init pointer, all of which eventually call down toaac_init_adapter().If aac_init_adapter() fails after allocating memory for aac_dev::queues,it frees the memory but does not clear that member.After the hardware-specific init function returns an error,aac_probe_one() goes down an error path that frees the memory pointed toby aac_dev::queues, resulting.in a double-free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50183 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instanceDeleting an NPIV instance requires all fabric ndlps to be released beforean NPIV's resources can be torn down. Failure to release fabric ndlpsbeforehand opens kref imbalance race conditions. Fix by forcing the DA_IDto complete synchronously with usage of wait_queue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57917 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:topology: Keep the cpumask unchanged when printing cpumapDuring fuzz testing, the following warning was discovered: different return values (15 and 11) from vsnprintf("%*pbl ", ...) test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmap_print_to_buf+0x89/0x100 core_siblings_list_read+0x7e/0xb0 kernfs_file_read_iter+0x15b/0x270 new_sync_read+0x153/0x260 vfs_read+0x215/0x290 ksys_read+0xb9/0x160 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2The call trace shows that kvasprintf() reported this warning during theprinting of core_siblings_list. kvasprintf() has several steps: (1) First, calculate the length of the resulting formatted string. (2) Allocate a buffer based on the returned length. (3) Then, perform the actual string formatting. (4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent.If the core_cpumask is modified between steps (1) and (3), the lengthsobtained in these two steps may not match. Indeed our test includes cpuhotplugging, which should modify core_cpumask while printing.To fix this issue, cache the cpumask into a temporary variable beforecalling cpumap_print_{list, cpumask}_to_buf(), to keep it unchangedduring the printing process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Don't reference skb after sending to VIOSPreviously, after successfully flushing the xmit buffer to VIOS,the tx_bytes stat was incremented by the length of the skb.It is invalid to access the skb memory after sending the buffer tothe VIOS because, at any point after sending, the VIOS can triggeran interrupt to free this memory. A race between reading skb->lenand freeing the skb is possible (especially during LPM) and willresult in use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic] Read of size 4 at addr c00000024eb48a70 by task hxecom/14495 <...> Call Trace: [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable) [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0 [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8 [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0 [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic] [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358 <...> Freed by task 0: kasan_save_stack+0x34/0x68 kasan_save_track+0x2c/0x50 kasan_save_free_info+0x64/0x108 __kasan_mempool_poison_object+0x148/0x2d4 napi_skb_cache_put+0x5c/0x194 net_tx_action+0x154/0x5b8 handle_softirqs+0x20c/0x60c do_softirq_own_stack+0x6c/0x88 <...> The buggy address belongs to the object at c00000024eb48a00 which belongs to the cache skbuff_head_cache of size 224==================================================================

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_gate: snapshot parameters with RCU on replaceThe gate action can be replaced while the hrtimer callback or dump path iswalking the schedule list.Convert the parameters to an RCU-protected snapshot and swap updates undertcf_lock, freeing the previous snapshot via call_rcu(). When REPLACE omitsthe entry list, preserve the existing schedule so the effective state isunchanged.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscsWhen shrinking the number of real tx queues,netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flushqdiscs for queues which will no longer be used.qdisc_reset_all_tx_gt() currently serializes qdisc_reset() withqdisc_lock(). However, for lockless qdiscs, the dequeue path isserialized by qdisc_run_begin/end() using qdisc->seqlock instead, soqdisc_reset() can run concurrently with __qdisc_run() and free skbswhile they are still being dequeued, leading to UAF.This can easily be reproduced on e.g. virtio-net by imposing heavytraffic while frequently changing the number of queue pairs: iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 doneWith KASAN enabled, this leads to reports like: BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: ... __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 udp_sendmsg+0x13c9/0x1fc0 ... Allocated by task 1270 on cpu 5 at 44.558414s: ... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg+0x13a6/0x1fc0 ... Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a/0x890 ...Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path bytaking qdisc->seqlock for TCQ_F_NOLOCK qdiscs, matching theserialization model already used by dev_reset_queue().Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc statereflects an empty queue, avoiding needless re-scheduling.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: fix use-after-free in mana_hwc_destroy_channel() by reordering teardownA potential race condition exists in mana_hwc_destroy_channel() wherehwc->caller_ctx is freed before the HWC's Completion Queue (CQ) andEvent Queue (EQ) are destroyed. This allows an in-flight CQ interrupthandler to dereference freed memory, leading to a use-after-free orNULL pointer dereference in mana_hwc_handle_resp().mana_smc_teardown_hwc() signals the hardware to stop but does notsynchronize against IRQ handlers already executing on other CPUs. TheIRQ synchronization only happens in mana_hwc_destroy_cq() viamana_gd_destroy_eq() -> mana_gd_deregister_irq(). Since this runsafter kfree(hwc->caller_ctx), a concurrent mana_hwc_rx_event_handler()can dereference freed caller_ctx (and rxq->msg_buf) inmana_hwc_handle_resp().Fix this by reordering teardown to reverse-of-creation order: destroythe TX/RX work queues and CQ/EQ before freeing hwc->caller_ctx. Thisensures all in-flight interrupt handlers complete before the memory theyaccess is freed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is falseA UAF issue occurs when the virtio_net driver is configured with napi_tx=Nand the device's IFF_XMIT_DST_RELEASE flag is cleared(e.g., during the configuration of tc route filter rules).When IFF_XMIT_DST_RELEASE is removed from the net_device, the network stackexpects the driver to hold the reference to skb->dst until the packetis fully transmitted and freed. In virtio_net with napi_tx=N,skbs may remain in the virtio transmit ring for an extended period.If the network namespace is destroyed while these skbs are still pending,the corresponding dst_ops structure has freed. When a subsequent packetis transmitted, free_old_xmit() is triggered to clean up old skbs.It then calls dst_release() on the skb associated with the stale dst_entry.Since the dst_ops (referenced by the dst_entry) has already been freed,a UAF kernel paging request occurs.fix it by adds skb_dst_drop(skb) in start_xmit to explicitly releasethe dst reference before the skb is queued in virtio_net.Call Trace: Unable to handle kernel paging request at virtual address ffff80007e150000 CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT ... percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P) dst_release+0xe0/0x110 net/core/dst.c:177 skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177 sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255 dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469 napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527 __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net] free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net] start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net] ...Reproduction Steps:NETDEV="enp3s0"config_qdisc_route_filter() { tc qdisc del dev $NETDEV root tc qdisc add dev $NETDEV root handle 1: prio tc filter add dev $NETDEV parent 1:0 \ protocol ip prio 100 route to 100 flowid 1:1 ip route add 192.168.1.100/32 dev $NETDEV realm 100}test_ns() { ip netns add testns ip link set $NETDEV netns testns ip netns exec testns ifconfig $NETDEV 10.0.32.46/24 ip netns exec testns ping -c 1 10.0.32.1 ip netns del testns}config_qdisc_route_filtertest_nssleep 2test_ns

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/efa: Fix use of completion ctx after freeOn admin queue completion handling, if the admin command completed witherror we print data from the completion context. The issue is that wealready freed the completion context in polling/interrupts handler whichmeans we print data from context in an unknown state (it might bealready used again).Change the admin submission flow so alloc/dealloc of the context will besymmetric and dealloc will be called after any potential use of thecontext.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:team: fix header_ops type confusion with non-Ethernet portsSimilar to commit 950803f72547 ("bonding: fix type confusion inbond_setup_by_slave()") team has the same class of header_ops typeconfusion.For non-Ethernet ports, team_setup_by_port() copies port_dev->header_opsdirectly. When the team device later calls dev_hard_header() ordev_parse_header(), these callbacks can run with the team net_deviceinstead of the real lower device, so netdev_priv(dev) is interpreted asthe wrong private type and can crash.The syzbot report shows a crash in bond_header_create(), but the rootcause is in team: the topology is gre -> bond -> team, and team callsthe inherited header_ops with its own net_device instead of the lowerdevice, so bond_header_create() receives a team device and interpretsnetdev_priv() as bonding private data, causing a type confusion crash.Fix this by introducing team header_ops wrappers for create/parse,selecting a team port under RCU, and calling the lower device callbackswith port->dev, so each callback always sees the correct net_devicecontext.Also pass the selected lower device to the lower parse callback, sorecursion is bounded in stacked non-Ethernet topologies and parsecallbacks always run with the correct device context.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: prevent policy_hthresh.work from racing with netns teardownA XFRM_MSG_NEWSPDINFO request can queue the per-net work itempolicy_hthresh.work onto the system workqueue.The queued callback, xfrm_hash_rebuild(), retrieves the enclosingstruct net via container_of(). If the net namespace is torn downbefore that work runs, the associated struct net may already havebeen freed, and xfrm_hash_rebuild() may then dereference stale memory.xfrm_policy_fini() already flushes policy_hash_work during teardown,but it does not synchronize policy_hthresh.work.Synchronize policy_hthresh.work in xfrm_policy_fini() as well, so thequeued work cannot outlive the net namespace teardown and access afreed struct net.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:driver core: platform: use generic driver_override infrastructureWhen a driver is probed through __driver_attach(), the bus' match()callback is called without the device lock held, thus accessing thedriver_override field without a lock, which can cause a UAF.Fix this by using the driver-core driver_override infrastructure takingcare of proper locking internally.Note that calling match() from __driver_attach() without the device lockheld is intentional. [1]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:can: raw: fix ro->uniq use-after-free in raw_rcv()raw_release() unregisters raw CAN receive filters via can_rx_unregister(),but receiver deletion is deferred with call_rcu(). This leaves a windowwhere raw_rcv() may still be running in an RCU read-side critical sectionafter raw_release() frees ro->uniq, leading to a use-after-free of thepercpu uniq storage.Move free_percpu(ro->uniq) out of raw_release() and into a raw-specificsocket destructor. can_rx_unregister() takes an extra reference to thesocket and only drops it from the RCU callback, so freeing uniq fromsk_destruct ensures the percpu area is not released until the relevantcallbacks have drained.[mkl: applied manually]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: 6fire: fix use-after-free on disconnectIn usb6fire_chip_abort(), the chip struct is allocated as the card'sprivate data (via snd_card_new with sizeof(struct sfire_chip)). Whensnd_card_free_when_closed() is called and no file handles are open, thecard and embedded chip are freed synchronously. The subsequentchip->card = NULL write then hits freed slab memory.Call trace: usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline] usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953Fix by moving the card lifecycle out of usb6fire_chip_abort() and intousb6fire_chip_disconnect(). The card pointer is saved in a localbefore any teardown, snd_card_disconnect() is called first to preventnew opens, URBs are aborted while chip is still valid, andsnd_card_free_when_closed() is called last so chip is never accessedafter the card may be freed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: hold claim backbone gateways by referencebatadv_bla_add_claim() can replace claim->backbone_gw and drop the oldgateway's last reference while readers still follow the pointer.The netlink claim dump path dereferences claim->backbone_gw->orig andtakes claim->backbone_gw->crc_lock without pinning the underlyingbackbone gateway. batadv_bla_check_claim() still has the same nakedpointer access pattern.Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operateon a stable gateway reference until the read-side work is complete.This keeps the dump and claim-check paths aligned with the lifetimerules introduced for the other BLA claim readers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: hold dev ref until after transport_finish NF_HOOKAfter async crypto completes, xfrm_input_resume() calls dev_put()immediately on re-entry before the skb reaches transport_finish.The skb->dev pointer is then used inside NF_HOOK and its okfn,which can race with device teardown.Remove the dev_put from the async resumption entry and insteaddrop the reference after the NF_HOOK call in transport_finish,using a saved device pointer since NF_HOOK may consume the skb.This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skipthe okfn.For non-transport exits (decaps, gro, drop) and secondaryasync return points, release the reference inline whenasync is set.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: fix use-after-free in timeout object destroynft_ct_timeout_obj_destroy() frees the timeout object with kfree()immediately after nf_ct_untimeout(), without waiting for an RCU graceperiod. Concurrent packet processing on other CPUs may still holdRCU-protected references to the timeout object obtained viarcu_dereference() in nf_ct_timeout_data().Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to deferfreeing until after an RCU grace period, matching the approach alreadyused in nfnetlink_cttimeout.c.KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: defer tunnel netdev_put to RCU releaseovs_netdev_tunnel_destroy() may run after NETDEV_UNREGISTER alreadydetached the device. Dropping the netdev reference in destroy can racewith concurrent readers that still observe vport->dev.Do not release vport->dev in ovs_netdev_tunnel_destroy(). Instead, letvport_netdev_free() drop the reference from the RCU callback, matchingthe non-tunnel destroy path and avoiding additional synchronizationunder RTNL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

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

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp: Don't attempt to copy ID to userspace if PSP command failedWhen retrieving the ID for the CPU, don't attempt to copy the ID blob touserspace if the firmware command failed. If the failure was due to aninvalid length, i.e. the userspace buffer+length was too small, copyingthe number of bytes _firmware_ requires will overflow the kernel-allocatedbuffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388 CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error codesays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on anyfirwmware error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failedWhen retrieving the PDH cert, don't attempt to copy the blobs to userspaceif the firmware command failed. If the failure was due to an invalidlength, i.e. the userspace buffer+length was too small, copying the numberof bytes _firmware_ requires will overflow the kernel-allocated buffer andleak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033 CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error codesays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on anyfirwmware error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failedWhen retrieving the PEK CSR, don't attempt to copy the blob to userspaceif the firmware command failed. If the failure was due to an invalidlength, i.e. the userspace buffer+length was too small, copying the numberof bytes _firmware_ requires will overflow the kernel-allocated buffer andleak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405 CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error codesays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on anyfirwmware error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.225.2 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: validate connector number in ucsi_notify_common()The connector number extracted from CCI via UCSI_CCI_CONNECTOR() is a7-bit field (0-127) that is used to index into the connector array inucsi_connector_change(). However, the array is only allocated for thenumber of connectors reported by the device (typically 2-4 entries).A malicious or malfunctioning device could report an out-of-rangeconnector number in the CCI, causing an out-of-bounds array access inucsi_connector_change().Add a bounds check in ucsi_notify_common(), the central point where CCIis parsed after arriving from hardware, so that bogus connector numbersare rejected before they propagate further.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, in a network-exposed cupsd with a shared target queue, an unauthorized client can send a Print-Job to that shared PostScript queue without authentication. The server accepts a page-border value supplied as textWithoutLanguage, preserves an embedded newline through option escaping and reparse, and then reparses the resulting second-line PPD: text as a trusted scheduler control record. A follow-up raw print job can therefore make the server execute an attacker-chosen existing binary such as /usr/bin/vim as lp. At time of publication, there are no publicly available patches.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
cups-config > 0-0 (version in image is 2.2.7-150000.3.86.1).

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

Description: In nspawn in systemd 233 through 259 before 260, an escape-to-host action can occur via a crafted optional config file.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libsystemd0 > 0-0 (version in image is 249.17-150400.8.55.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:hwrng: core - use RCU and work_struct to fix race conditionCurrently, hwrng_fill is not cleared until the hwrng_fillfn() threadexits. Since hwrng_unregister() reads hwrng_fill outside the rng_mutexlock, a concurrent hwrng_unregister() may call kthread_stop() again onthe same task.Additionally, if hwrng_unregister() is called immediately afterhwrng_register(), the stopped thread may have never been executed. Thus,hwrng_fill remains dirty even after hwrng_unregister() returns. In thiscase, subsequent calls to hwrng_register() will fail to start newthreads, and hwrng_unregister() will call kthread_stop() on the samefreed task. In both cases, a use-after-free occurs:refcount_t: addition on 0; use-after-free.WARNING: ... at lib/refcount.c:25 refcount_warn_saturate+0xec/0x1c0Call Trace: kthread_stop+0x181/0x360 hwrng_unregister+0x288/0x380 virtrng_remove+0xe3/0x200This patch fixes the race by protecting the global hwrng_fill pointerinside the rng_mutex lock, so that hwrng_fillfn() thread is stopped onlyonce, and calls to kthread_run() and kthread_stop() are serializedwith the lock held.To avoid deadlock in hwrng_fillfn() while being stopped with the lockheld, we convert current_rng to RCU, so that get_current_rng() can readcurrent_rng without holding the lock. To remove the lock from put_rng(),we also delay the actual cleanup into a work_struct.Since get_current_rng() no longer returns ERR_PTR values, the IS_ERR()checks are removed from its callers.With hwrng_fill protected by the rng_mutex lock, hwrng_fillfn() can nolonger clear hwrng_fill itself. Therefore, if hwrng_fillfn() returnsdirectly after current_rng is dropped, kthread_stop() would be called ona freed task_struct later. To fix this, hwrng_fillfn() calls schedule()now to keep the task alive until being stopped. The kthread_stop() callis also moved from hwrng_unregister() to drop_current_rng(), ensuringkthread_stop() is called on all possible paths where current_rng becomesNULL, so that the thread would not wait forever.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:udf: fix partition descriptor append bookkeepingMounting a crafted UDF image with repeated partition descriptors cantrigger a heap out-of-bounds write in part_descs_loc[].handle_partition_descriptor() deduplicates entries by partition number,but appended slots never record partnum. As a result duplicatePartition Descriptors are appended repeatedly and num_part_descs keepsgrowing.Once the table is full, the growth path still sizes the allocation frompartnum even though inserts are indexed by num_part_descs. If partnum isalready aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keepthe old capacity and the next append writes past the end of the table.Store partnum in the appended slot and size growth from the next appendcount so deduplication and capacity tracking follow the same model.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: ns: Fix use-after-free in driver remove()In the remove callback, if a packet arrives after destroy_workqueue() iscalled, but before sock_release(), the qrtr_ns_data_ready() callback willtry to queue the work, causing use-after-free issue.Fix this issue by saving the default 'sk_data_ready' callback duringqrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback atthe start of remove(). This ensures that even if a packet arrives afterdestroy_workqueue(), the work struct will not be dereferenced.Note that it is also required to ensure that the RX threads are completedbefore destroying the workqueue, because the threads could be using theqrtr_ns_data_ready() callback.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:spi: topcliff-pch: fix use-after-free on unbindGive the driver a chance to flush its queue before releasing the DMAbuffers on driver unbind

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50315 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTSUBSAN complains about array-index-out-of-bounds:[ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41[ 1.980709] kernel: index 15 is out of range for type 'ahci_em_priv [8]'[ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu[ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010[ 1.980718] kernel: Call Trace:[ 1.980721] kernel: [ 1.980723] kernel: show_stack+0x52/0x58[ 1.980729] kernel: dump_stack_lvl+0x4a/0x5f[ 1.980734] kernel: dump_stack+0x10/0x12[ 1.980736] kernel: ubsan_epilogue+0x9/0x45[ 1.980739] kernel: __ubsan_handle_out_of_bounds.cold+0x44/0x49[ 1.980742] kernel: ahci_qc_issue+0x166/0x170 [libahci][ 1.980748] kernel: ata_qc_issue+0x135/0x240[ 1.980752] kernel: ata_exec_internal_sg+0x2c4/0x580[ 1.980754] kernel: ? vprintk_default+0x1d/0x20[ 1.980759] kernel: ata_exec_internal+0x67/0xa0[ 1.980762] kernel: sata_pmp_read+0x8d/0xc0[ 1.980765] kernel: sata_pmp_read_gscr+0x3c/0x90[ 1.980768] kernel: sata_pmp_attach+0x8b/0x310[ 1.980771] kernel: ata_eh_revalidate_and_attach+0x28c/0x4b0[ 1.980775] kernel: ata_eh_recover+0x6b6/0xb30[ 1.980778] kernel: ? ahci_do_hardreset+0x180/0x180 [libahci][ 1.980783] kernel: ? ahci_stop_engine+0xb0/0xb0 [libahci][ 1.980787] kernel: ? ahci_do_softreset+0x290/0x290 [libahci][ 1.980792] kernel: ? trace_event_raw_event_ata_eh_link_autopsy_qc+0xe0/0xe0[ 1.980795] kernel: sata_pmp_eh_recover.isra.0+0x214/0x560[ 1.980799] kernel: sata_pmp_error_handler+0x23/0x40[ 1.980802] kernel: ahci_error_handler+0x43/0x80 [libahci][ 1.980806] kernel: ata_scsi_port_error_handler+0x2b1/0x600[ 1.980810] kernel: ata_scsi_error+0x9c/0xd0[ 1.980813] kernel: scsi_error_handler+0xa1/0x180[ 1.980817] kernel: ? scsi_unjam_host+0x1c0/0x1c0[ 1.980820] kernel: kthread+0x12a/0x150[ 1.980823] kernel: ? set_kthread_struct+0x50/0x50[ 1.980826] kernel: ret_from_fork+0x22/0x30[ 1.980831] kernel: This happens because sata_pmp_init_links() initialize link->pmp up toSATA_PMP_MAX_PORTS while em_priv is declared as 8 elements array.I can't find the maximum Enclosure Management ports specified in AHCIspec v1.3.1, but "12.2.1 LED message type" states that "Port MultiplierInformation" can utilize 4 bits, which implies it can support up to 16ports. Hence, use SATA_PMP_MAX_PORTS as EM_MAX_SLOTS to resolve theissue.BugLink: https://bugs.launchpad.net/bugs/1970074

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50720 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:x86/apic: Don't disable x2APIC if lockedThe APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC(or x2APIC). X2APIC mode is mostly compatible with legacy APIC, butit disables the memory-mapped APIC interface in favor of one that usesMSRs. The APIC mode is controlled by the EXT bit in the APIC MSR.The MMIO/xAPIC interface has some problems, most notably the APIC LEAK[1]. This bug allows an attacker to use the APIC MMIO interface toextract data from the SGX enclave.Introduce support for a new feature that will allow the BIOS to lockthe APIC in x2APIC mode. If the APIC is locked in x2APIC mode and thekernel tries to disable the APIC or revert to legacy APIC mode a GPfault will occur.Introduce support for a new MSR (IA32_XAPIC_DISABLE_STATUS) and handlethe new locked mode when the LEGACY_XAPIC_DISABLED bit is set bypreventing the kernel from trying to disable the x2APIC.On platforms with the IA32_XAPIC_DISABLE_STATUS MSR, if SGX or TDX areenabled the LEGACY_XAPIC_DISABLED will be set by the BIOS. Iflegacy APIC is required, then it SGX and TDX need to be disabled in theBIOS.[1]: https://aepicleak.com/aepicleak.pdf

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50764 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6/sit: use DEV_STATS_INC() to avoid data-racessyzbot/KCSAN reported that multiple cpus are updating dev->stats.tx_errorconcurrently.This is because sit tunnels are NETIF_F_LLTX, meaning their ndo_start_xmit()is not protected by a spinlock.While original KCSAN report was about tx path, rx path has the same issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53623 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:mm/swap: fix swap_info_struct race between swapoff and get_swap_pages()The si->lock must be held when deleting the si from the available list. Otherwise, another thread can re-add the si to the available list, whichcan lead to memory corruption. The only place we have found where thishappens is in the swapoff path. This case can be described as below:core 0 core 1swapoffdel_from_avail_list(si) waitingtry lock si->lock acquire swap_avail_lock and re-add si into swap_avail_headacquire si->lock but missing si already being added again, and continuingto clear SWP_WRITEOK, etc.It can be easily found that a massive warning messages can be triggeredinside get_swap_pages() by some special cases, for example, we callmadvise(MADV_PAGEOUT) on blocks of touched memory concurrently, meanwhile,run much swapon-swapoff operations (e.g. stress-ng-swap).However, in the worst case, panic can be caused by the above scene. Inswapoff(), the memory used by si could be kept in swap_info[] afterturning off a swap. This means memory corruption will not be causedimmediately until allocated and reset for a new swap in the swapon path. A panic message caused: (with CONFIG_PLIST_DEBUG enabled)------------[ cut here ]------------top: 00000000e58a3003, n: 0000000013e75cda, p: 000000008cd4451aprev: 0000000035b1e58a, n: 000000008cd4451a, p: 000000002150ee8dnext: 000000008cd4451a, n: 000000008cd4451a, p: 000000008cd4451aWARNING: CPU: 21 PID: 1843 at lib/plist.c:60 plist_check_prev_next_node+0x50/0x70Modules linked in: rfkill(E) crct10dif_ce(E)...CPU: 21 PID: 1843 Comm: stress-ng Kdump: ... 5.10.134+Hardware name: Alibaba Cloud ECS, BIOS 0.0.0 02/06/2015pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)pc : plist_check_prev_next_node+0x50/0x70lr : plist_check_prev_next_node+0x50/0x70sp : ffff0018009d3c30x29: ffff0018009d3c40 x28: ffff800011b32a98x27: 0000000000000000 x26: ffff001803908000x25: ffff8000128ea088 x24: ffff800011b32a48x23: 0000000000000028 x22: ffff001800875c00x21: ffff800010f9e520 x20: ffff001800875c00x19: ffff001800fdc6e0 x18: 0000000000000030x17: 0000000000000000 x16: 0000000000000000x15: 0736076307640766 x14: 0730073007380731x13: 0736076307640766 x12: 0730073007380731x11: 000000000004058d x10: 0000000085a85b76x9 : ffff8000101436e4 x8 : ffff800011c8ce08x7 : 0000000000000000 x6 : 0000000000000001x5 : ffff0017df9ed338 x4 : 0000000000000001x3 : ffff8017ce62a000 x2 : ffff0017df9ed340x1 : 0000000000000000 x0 : 0000000000000000Call trace: plist_check_prev_next_node+0x50/0x70 plist_check_head+0x80/0xf0 plist_add+0x28/0x140 add_to_avail_list+0x9c/0xf0 _enable_swap_info+0x78/0xb4 __do_sys_swapon+0x918/0xa10 __arm64_sys_swapon+0x20/0x30 el0_svc_common+0x8c/0x220 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180irq event stamp: 2082270Now, si->lock locked before calling 'del_from_avail_list()' to make sureother thread see the si had been deleted and SWP_WRITEOK cleared together,will not reinsert again.This problem exists in versions after stable 5.10.y.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54068 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: compress: fix to call f2fs_wait_on_page_writeback() in f2fs_write_raw_pages()BUG_ON() will be triggered when writing files concurrently,because the same page is writtenback multiple times.1597 void folio_end_writeback(struct folio *folio)1598 { ......1618 if (!__folio_end_writeback(folio))1619 BUG(); ......1625 }kernel BUG at mm/filemap.c:1619!Call Trace: f2fs_write_end_io+0x1a0/0x370 blk_update_request+0x6c/0x410 blk_mq_end_request+0x15/0x130 blk_complete_reqs+0x3c/0x50 __do_softirq+0xb8/0x29b ? sort_range+0x20/0x20 run_ksoftirqd+0x19/0x20 smpboot_thread_fn+0x10b/0x1d0 kthread+0xde/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 Below is the concurrency scenario:[Process A] [Process B] [Process C]f2fs_write_raw_pages() - redirty_page_for_writepage() - unlock page() f2fs_do_write_data_page() - lock_page() - clear_page_dirty_for_io() - set_page_writeback() [1st writeback] ..... - unlock page() generic_perform_write() - f2fs_write_begin() - wait_for_stable_page() - f2fs_write_end() - set_page_dirty() - lock_page() - f2fs_do_write_data_page() - set_page_writeback() [2st writeback]This problem was introduced by the previous commit 7377e853967b ("f2fs:compress: fix potential deadlock of compress file"). All pagelocks werereleased in f2fs_write_raw_pages(), but whether the page wasin the writeback state was ignored in the subsequent writing process.Let's fix it by waiting for the page to writeback before writing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54128 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:fs: drop peer group ids under namespace lockWhen cleaning up peer group ids in the failure path we need to make sureto hold on to the namespace lock. Otherwise another thread might justturn the mount from a shared into a non-shared mount concurrently.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54137 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:vfio/type1: fix cap_migration information leakFix an information leak where an uninitialized hole in structvfio_iommu_type1_info_cap_migration on the stack is exposed to userspace.The definition of struct vfio_iommu_type1_info_cap_migration contains a hole asshown in this pahole(1) output: struct vfio_iommu_type1_info_cap_migration { struct vfio_info_cap_header header; /* 0 8 */ __u32 flags; /* 8 4 */ /* XXX 4 bytes hole, try to pack */ __u64 pgsize_bitmap; /* 16 8 */ __u64 max_dirty_bitmap_size; /* 24 8 */ /* size: 32, cachelines: 1, members: 4 */ /* sum members: 28, holes: 1, sum holes: 4 */ /* last cacheline: 32 bytes */ };The cap_mig variable is filled in without initializing the hole: static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu, struct vfio_info_cap *caps) { struct vfio_iommu_type1_info_cap_migration cap_mig; cap_mig.header.id = VFIO_IOMMU_TYPE1_INFO_CAP_MIGRATION; cap_mig.header.version = 1; cap_mig.flags = 0; /* support minimum pgsize */ cap_mig.pgsize_bitmap = (size_t)1 << __ffs(iommu->pgsize_bitmap); cap_mig.max_dirty_bitmap_size = DIRTY_BITMAP_SIZE_MAX; return vfio_info_add_capability(caps, &cap_mig.header, sizeof(cap_mig)); }The structure is then copied to a temporary location on the heap. At this pointit's already too late and ioctl(VFIO_IOMMU_GET_INFO) copies it to userspacelater: int vfio_info_add_capability(struct vfio_info_cap *caps, struct vfio_info_cap_header *cap, size_t size) { struct vfio_info_cap_header *header; header = vfio_info_cap_add(caps, size, cap->id, cap->version); if (IS_ERR(header)) return PTR_ERR(header); memcpy(header + 1, cap + 1, size - sizeof(*header)); return 0; }This issue was found by code inspection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54200 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: always release netdev hooks from notifierThis reverts "netfilter: nf_tables: skip netdev events generated on netns removal".The problem is that when a veth device is released, the veth releasecallback will also queue the peer netns device for removal.Its possible that the peer netns is also slated for removal. In thiscase, the device memory is already released before the pre_exit hook ofthe peer netns runs:BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45Workqueue: netns cleanup_netCall Trace: nf_hook_entry_head+0x1b8/0x1d0 __nf_unregister_net_hook+0x76/0x510 nft_netdev_unregister_hooks+0xa0/0x220 __nft_release_hook+0x184/0x490 nf_tables_pre_exit_net+0x12f/0x1b0 ..Order is:1. First netns is released, veth_dellink() queues peer netns device for removal2. peer netns is queued for removal3. peer netns device is released, unreg event is triggered4. unreg event is ignored because netns is going down5. pre_exit hook calls nft_netdev_unregister_hooks but device memory might be free'd already.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54257 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: fix a memory corruption in extended buffer descriptor modeFor quite some time we were chasing a bug which looked like a suddenpermanent failure of networking and mmc on some of our devices.The bug was very sensitive to any software changes and even more toany kernel debug options.Finally we got a setup where the problem was reproducible withCONFIG_DMA_API_DEBUG=y and it revealed the issue with the rx dma:[ 16.992082] ------------[ cut here ]------------[ 16.996779] DMA-API: macb ff0b0000.ethernet: device driver tries to free DMA memory it has not allocated [device address=0x0000000875e3e244] [size=1536 bytes][ 17.011049] WARNING: CPU: 0 PID: 85 at kernel/dma/debug.c:1011 check_unmap+0x6a0/0x900[ 17.018977] Modules linked in: xxxxx[ 17.038823] CPU: 0 PID: 85 Comm: irq/55-8000f000 Not tainted 5.4.0 #28[ 17.045345] Hardware name: xxxxx[ 17.049528] pstate: 60000005 (nZCv daif -PAN -UAO)[ 17.054322] pc : check_unmap+0x6a0/0x900[ 17.058243] lr : check_unmap+0x6a0/0x900[ 17.062163] sp : ffffffc010003c40[ 17.065470] x29: ffffffc010003c40 x28: 000000004000c03c[ 17.070783] x27: ffffffc010da7048 x26: ffffff8878e38800[ 17.076095] x25: ffffff8879d22810 x24: ffffffc010003cc8[ 17.081407] x23: 0000000000000000 x22: ffffffc010a08750[ 17.086719] x21: ffffff8878e3c7c0 x20: ffffffc010acb000[ 17.092032] x19: 0000000875e3e244 x18: 0000000000000010[ 17.097343] x17: 0000000000000000 x16: 0000000000000000[ 17.102647] x15: ffffff8879e4a988 x14: 0720072007200720[ 17.107959] x13: 0720072007200720 x12: 0720072007200720[ 17.113261] x11: 0720072007200720 x10: 0720072007200720[ 17.118565] x9 : 0720072007200720 x8 : 000000000000022d[ 17.123869] x7 : 0000000000000015 x6 : 0000000000000098[ 17.129173] x5 : 0000000000000000 x4 : 0000000000000000[ 17.134475] x3 : 00000000ffffffff x2 : ffffffc010a1d370[ 17.139778] x1 : b420c9d75d27bb00 x0 : 0000000000000000[ 17.145082] Call trace:[ 17.147524] check_unmap+0x6a0/0x900[ 17.151091] debug_dma_unmap_page+0x88/0x90[ 17.155266] gem_rx+0x114/0x2f0[ 17.158396] macb_poll+0x58/0x100[ 17.161705] net_rx_action+0x118/0x400[ 17.165445] __do_softirq+0x138/0x36c[ 17.169100] irq_exit+0x98/0xc0[ 17.172234] __handle_domain_irq+0x64/0xc0[ 17.176320] gic_handle_irq+0x5c/0xc0[ 17.179974] el1_irq+0xb8/0x140[ 17.183109] xiic_process+0x5c/0xe30[ 17.186677] irq_thread_fn+0x28/0x90[ 17.190244] irq_thread+0x208/0x2a0[ 17.193724] kthread+0x130/0x140[ 17.196945] ret_from_fork+0x10/0x20[ 17.200510] ---[ end trace 7240980785f81d6f ]---[ 237.021490] ------------[ cut here ]------------[ 237.026129] DMA-API: exceeded 7 overlapping mappings of cacheline 0x0000000021d79e7b[ 237.033886] WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:499 add_dma_entry+0x214/0x240[ 237.041802] Modules linked in: xxxxx[ 237.061637] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.4.0 #28[ 237.068941] Hardware name: xxxxx[ 237.073116] pstate: 80000085 (Nzcv daIf -PAN -UAO)[ 237.077900] pc : add_dma_entry+0x214/0x240[ 237.081986] lr : add_dma_entry+0x214/0x240[ 237.086072] sp : ffffffc010003c30[ 237.089379] x29: ffffffc010003c30 x28: ffffff8878a0be00[ 237.094683] x27: 0000000000000180 x26: ffffff8878e387c0[ 237.099987] x25: 0000000000000002 x24: 0000000000000000[ 237.105290] x23: 000000000000003b x22: ffffffc010a0fa00[ 237.110594] x21: 0000000021d79e7b x20: ffffffc010abe600[ 237.115897] x19: 00000000ffffffef x18: 0000000000000010[ 237.121201] x17: 0000000000000000 x16: 0000000000000000[ 237.126504] x15: ffffffc010a0fdc8 x14: 0720072007200720[ 237.131807] x13: 0720072007200720 x12: 0720072007200720[ 237.137111] x11: 0720072007200720 x10: 0720072007200720[ 237.142415] x9 : 0720072007200720 x8 : 0000000000000259[ 237.147718] x7 : 0000000000000001 x6 : 0000000000000000[ 237.15302---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54324 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix a race condition in retrieve_depsThere's a race condition in the multipath target when retrieve_depsraces with multipath_message calling dm_get_device and dm_put_device.retrieve_deps walks the list of open devices without holding any lockbut multipath may add or remove devices to the list while it isrunning. The end result may be memory corruption or use-after-freememory access.See this description of a UAF with multipath_message():https://listman.redhat.com/archives/dm-devel/2022-October/052373.htmlFix this bug by introducing a new rw semaphore "devices_lock". We grabdevices_lock for read in retrieve_deps and we grab it for write indm_get_device and dm_put_device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: A race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:init/main.c: Fix potential static_command_line memory overflowWe allocate memory of size 'xlen + strlen(boot_command_line) + 1' forstatic_command_line, but the strings copied into static_command_line areextra_command_line and command_line, rather than extra_command_line andboot_command_line.When strlen(command_line) > strlen(boot_command_line), static_command_linewill overflow.This patch just recovers strlen(command_line) which was miss-consolidatedwith strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: addchecks for the return value of memblock_alloc*()")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:enic: Validate length of nl attributes in enic_set_vf_portenic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILEis of length PORT_PROFILE_MAX and that the nl attributesIFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.These attributes are validated (in the function do_setlink in rtnetlink.c)using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILEas NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY andIFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validationusing the policy is for the max size of the attributes and not on exactsize so the length of these attributes might be less than the sizes thatenic_set_vf_port expects. This might cause an out of bandsread access in the memcpys of the data of theseattributes in enic_set_vf_port.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/io-wq: Use set_bit() and test_bit() at worker->flagsUtilize set_bit() and test_bit() on worker->flags within io_uring/io-wqto address potential data races.The structure io_worker->flags may be accessed through various datapaths, leading to concurrency issues. When KCSAN is enabled, it revealsdata races occurring in io_worker_handle_work andio_wq_activate_free_worker functions. BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28: io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569) io_wq_worker (io_uring/io-wq.c:?) read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5: io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285) io_wq_enqueue (io_uring/io-wq.c:947) io_queue_iowq (io_uring/io_uring.c:524) io_req_task_submit (io_uring/io_uring.c:1511) io_handle_tw_list (io_uring/io_uring.c:1198)Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' ofgit://git.kernel.org/pub/scm/virt/kvm/kvm").These races involve writes and reads to the same memory location bydifferent tasks running on different CPUs. To mitigate this, refactorthe code to use atomic operations such as set_bit(), test_bit(), andclear_bit() instead of basic "and" and "or" operations. This ensuresthread-safe manipulation of worker flags.Also, move `create_index` to avoid holes in the structure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:filelock: Fix fcntl/close race recovery compat pathWhen I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably whenfcntl/close race is detected"), I missed that there are two copies of thecode I was patching: The normal version, and the version for 64-bit offsetson 32-bit kernels.Thanks to Greg KH for stumbling over this while doing the stablebackport...Apply exactly the same fix to the compat path for 32-bit kernels.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: reject claimed-as-LCP but actually malformed packetsSince 'ppp_async_encode()' assumes valid LCP packets (with codefrom 1 to 7 inclusive), add 'ppp_check_packet()' to ensure thatLCP packet has an actual body beyond PPP_LCP header bytes, andreject claimed-as-LCP but actually malformed data otherwise.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ftruncate: pass a signed offsetThe old ftruncate() syscall, using the 32-bit off_t misses a signextension when called in compat mode on 64-bit architectures. As aresult, passing a negative length accidentally succeeds in truncatingto file size between 2GiB and 4GiB.Changing the type of the compat syscall to the signed compat_off_tchanges the behavior so it instead returns -EINVAL.The native entry point, the truncate() syscall and the correspondingloff_t based variants are all correct already and do not sufferfrom this mistake.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check smcd_v2_ext_offset when receiving proposal msgWhen receiving proposal msg in server, the field smcd_v2_ext_offset inproposal msg is from the remote client and can not be fully trusted.Once the value of smcd_v2_ext_offset exceed the max value, there hasthe chance to access wrong address, and crash may happen.This patch checks the value of smcd_v2_ext_offset before using it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msgWhen receiving proposal msg in server, the fields v2_ext_offset/eid_cnt/ism_gid_cnt in proposal msg are from the remote clientand can not be fully trusted. Especially the field v2_ext_offset,once exceed the max value, there has the chance to access wrongaddress, and crash may happen.This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cntbefore using them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msgWhen receiving proposal msg in server, the field iparea_offsetand the field ipv6_prefixes_cnt in proposal msg are from theremote client and can not be fully trusted. Especially thefield iparea_offset, once exceed the max value, there has thechance to access wrong address, and crash may happen.This patch checks iparea_offset and ipv6_prefixes_cnt before using them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Prevent tail call between progs attached to different hooksbpf progs can be attached to kernel functions, and the attached functionscan take different parameters or return different return values. Ifprog attached to one kernel function tail calls prog attached to anotherkernel function, the ctx access or return value verification could bebypassed.For example, if prog1 is attached to func1 which takes only 1 parameterand prog2 is attached to func2 which takes two parameters. Since verifierassumes the bpf ctx passed to prog2 is constructed based on func2'sprototype, verifier allows prog2 to access the second parameter fromthe bpf ctx passed to it. The problem is that verifier does not preventprog1 from passing its bpf ctx to prog2 via tail call. In this case,the bpf ctx passed to prog2 is constructed from func1 instead of func2,that is, the assumption for ctx access verification is bypassed.Another example, if BPF LSM prog1 is attached to hook file_alloc_security,and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifierknows the return value rules for these two hooks, e.g. it is legal forbpf_lsm_audit_rule_known to return positive number 1, and it is illegalfor file_alloc_security to return positive number. So verifier allowsprog2 to return positive number 1, but does not allow prog1 to returnpositive number. The problem is that verifier does not prevent prog1from calling prog2 via tail call. In this case, prog2's return value 1will be used as the return value for prog1's hook file_alloc_security.That is, the return value rule is bypassed.This patch adds restriction for tail call to prevent such bypasses.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: fix race condition between reset and nvme_dev_disable()nvme_dev_disable() modifies the dev->online_queues field, thereforenvme_pci_update_nr_queues() should avoid racing against it, otherwisewe could end up passing invalid values to blk_mq_update_nr_hw_queues(). WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pci_irq_get_affinity+0x187/0x210 Workqueue: nvme-reset-wq nvme_reset_work [nvme] RIP: 0010:pci_irq_get_affinity+0x187/0x210 Call Trace: ? blk_mq_pci_map_queues+0x87/0x3c0 ? pci_irq_get_affinity+0x187/0x210 blk_mq_pci_map_queues+0x87/0x3c0 nvme_pci_map_queues+0x189/0x460 [nvme] blk_mq_update_nr_hw_queues+0x2a/0x40 nvme_reset_work+0x1be/0x2a0 [nvme]Fix the bug by locking the shutdown_lock mutex before usingdev->online_queues. Give up if nvme_dev_disable() is running or ifit has been executed already.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: fix potential out-of-bounds access on the first resumeOut-of-bounds access occurs if the fast device is expanded unexpectedlybefore the first-time resume of the cache table. This happens becauseexpanding the fast device requires reloading the cache table forcache_create to allocate new in-core data structures that fit the newsize, and the check in cache_preresume is not performed during thefirst resume, leading to the issue.Reproduce steps:1. prepare component devices:dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc 262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate.dmsetup create cache --notabledmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"dmsetup resume cdatadmsetup resume cache3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40:dmsetup suspend cacheKASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by checking the size change on the first resume.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix race condition by adding filter's intermediate sync stateFix a race condition in the i40e driver that leads to MAC/VLAN filtersbecoming corrupted and leaking. Address the issue that occurs underheavy load when multiple threads are concurrently modifying MAC/VLANfilters by setting mac and port VLAN.1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan().2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac().3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption.Reproduction steps:1. Spawn multiple VFs.2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host.3. Observe errors in dmesg:"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, please set promiscuous on manually for VF XX".Exact code for stable reproduction Intel can't open-source now.The fix involves implementing a new intermediate filter state,I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.These filters cannot be deleted from the hash list directly butmust be removed using the full process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix out-of-bounds access of directory entriesIn the case of the directory size is greater than or equal tothe cluster size, if start_clu becomes an EOF cluster(an invalidcluster) due to file system corruption, then the directory entrywhere ei->hint_femp.eidx hint is outside the directory, resultingin an out-of-bounds access, which may cause further file systemcorruption.This commit adds a check for start_clu, if it is an invalid cluster,the file or directory will be treated as empty.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:ila: serialize calls to nf_register_net_hooks()syzbot found a race in ila_add_mapping() [1]commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner")attempted to fix a similar issue.Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.Add a mutex to make sure at most one thread is calling nf_register_net_hooks().[1] BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626 nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269 NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672 __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785 process_backlog+0x443/0x15f0 net/core/dev.c:6117 __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883 napi_poll net/core/dev.c:6952 [inline] net_rx_action+0xa94/0x1010 net/core/dev.c:7074 handle_softirqs+0x213/0x8f0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.83.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix double free of TCP_Server_Info::hostnameWhen shutting down the server in cifs_put_tcp_session(), cifsd threadmight be reconnecting to multiple DFS targets before it realizes itshould exit the loop, so @server->hostname can't be freed as long ascifsd thread isn't done. Otherwise the following can happen: RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __reconnect_target_unlocked+0x3e/0x160 [cifs] ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0xce/0x120 ? __slab_free+0x223/0x3c0 ? do_error_trap+0x65/0x80 ? __slab_free+0x223/0x3c0 ? exc_invalid_op+0x4e/0x70 ? __slab_free+0x223/0x3c0 ? asm_exc_invalid_op+0x16/0x20 ? __slab_free+0x223/0x3c0 ? extract_hostname+0x5c/0xa0 [cifs] ? extract_hostname+0x5c/0xa0 [cifs] ? __kmalloc+0x4b/0x140 __reconnect_target_unlocked+0x3e/0x160 [cifs] reconnect_dfs_server+0x145/0x430 [cifs] cifs_handle_standard+0x1ad/0x1d0 [cifs] cifs_demultiplex_thread+0x592/0x730 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: update channel list in reg notifier instead reg workerCurrently when ath11k gets a new channel list, it will be processedaccording to the following steps:1. update new channel list to cfg80211 and queue reg_work.2. cfg80211 handles new channel list during reg_work.3. update cfg80211's handled channel list to firmware byath11k_reg_update_chan_list().But ath11k will immediately execute step 3 after reg_work is justqueued. Since step 2 is asynchronous, cfg80211 may not have completedhandling the new channel list, which may leading to an out-of-boundswrite error:BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_listCall Trace: ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11k_regd_update+0x1cf/0x350 [ath11k] ath11k_regd_update_work+0x14/0x20 [ath11k] process_one_work+0xe35/0x14c0Should ensure step 2 is completely done before executing step 3. ThusWen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set,cfg80211 will notify ath11k after step 2 is done.So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 willnotify ath11k after step 2 is done. At this time, there will be noKASAN bug during the execution of the step 3.[1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Avoid race in open_cached_dir with lease breaksA pre-existing valid cfid returned from find_or_create_cached_dir mightrace with a lease break, meaning open_cached_dir doesn't consider itvalid, and thinks it's newly-constructed. This leaks a dentry referenceif the allocation occurs before the queued lease break work runs.Avoid the race by extending holding the cfid_list_lock acrossfind_or_create_cached_dir and when the result is checked.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: add locking for bcm_op runtime updatesThe CAN broadcast manager (CAN BCM) can send a sequence of CAN frames viahrtimer. The content and also the length of the sequence can be changedresp reduced at runtime where the 'currframe' counter is then set to zero.Although this appeared to be a safe operation the updates of 'currframe'can be triggered from user space and hrtimer context in bcm_can_tx().Anderson Nascimento created a proof of concept that triggered a KASANslab-out-of-bounds read access which can be prevented with a spin_lock_bh.At the rework of bcm_can_tx() the 'count' variable has been moved intothe protected section as this variable can be modified from both contextstoo.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:virtio: break and reset virtio devices on device_shutdown()Hongyu reported a hang on kexec in a VM. QEMU reported invalid memoryaccesses during the hang. Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected ...It was traced down to virtio-console. Kexec works fine if virtio-consoleis not in use.The issue is that virtio-console continues to write to the MMIO even afterunderlying virtio-pci device is reset.Additionally, Eric noticed that IOMMUs are reset before devices, ifdevices are not reset on shutdown they continue to poke at guest memoryand get errors from the IOMMU. Some devices get wedged then.The problem can be solved by breaking all virtio devices on virtiobus shutdown, then resetting them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: parse_dfs_referrals: prevent oob on malformed inputMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS- reply smaller than sizeof(struct get_dfs_referral_rsp)- reply with number of referrals smaller than NumberOfReferrals in theheaderProcessing of such replies will cause oob.Return -EINVAL error on such replies to prevent oob-s.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23056 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:uacce: implement mremap in uacce_vm_ops to return -EPERMThe current uacce_vm_ops does not support the mremap operation ofvm_operations_struct. Implement .mremap to return -EPERM to remindusers.The reason we need to explicitly disable mremap is that when thedriver does not implement .mremap, it uses the default mremapmethod. This could lead to a risk scenario:An application might first mmap address p1, then mremap to p2,followed by munmap(p1), and finally munmap(p2). Since the defaultmremap copies the original vma's vm_private_data (i.e., q) to thenew vma, both munmap operations would trigger vma_close, causingq->qfr to be freed twice(qfr will be set to null here, so repeatedrelease is ok).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23078 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: scarlett2: Fix buffer overflow in config retrievalThe scarlett2_usb_get_config() function has a logic error in theendianness conversion code that can cause buffer overflows whencount > 1.The code checks `if (size == 2)` where `size` is the total buffer size inbytes, then loops `count` times treating each element as u16 (2 bytes).This causes the loop to access `count * 2` bytes when the buffer onlyhas `size` bytes allocated.Fix by checking the element size (config_item->size) instead of thetotal buffer size. This ensures the endianness conversion matches theactual element type.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23262 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:gve: Fix stats report corruption on queue count changeThe driver and the NIC share a region in memory for stats reporting.The NIC calculates its offset into this region based on the total sizeof the stats region and the size of the NIC's stats.When the number of queues is changed, the driver's stats region isresized. If the queue count is increased, the NIC can write pastthe end of the allocated stats region, causing memory corruption.If the queue count is decreased, there is a gap between the driverand NIC stats, leading to incorrect stats reporting.This change fixes the issue by allocating stats region with maximumsize, and the offset calculation for NIC stats is changed to matchwith the calculation of the NIC.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23281 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: libertas: fix use-after-free in lbs_free_adapter()The lbs_free_adapter() function uses timer_delete() (non-synchronous)for both command_timer and tx_lockup_timer before the structure isfreed. This is incorrect because timer_delete() does not wait forany running timer callback to complete.If a timer callback is executing when lbs_free_adapter() is called,the callback will access freed memory since lbs_cfg_free() frees thecontaining structure immediately after lbs_free_adapter() returns.Both timer callbacks (lbs_cmd_timeout_handler and lbs_tx_lockup_handler)access priv->driver_lock, priv->cur_cmd, priv->dev, and other fields,which would all be use-after-free violations.Use timer_delete_sync() instead to ensure any running timer callbackhas completed before returning.This bug was introduced in commit 8f641d93c38a ("libertas: detect TXlockups and reset hardware") where del_timer() was used instead ofdel_timer_sync() in the cleanup path. The command_timer has had thesame issue since the driver was first written.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23367 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: radiotap: reject radiotap with unknown bitsThe radiotap parser is currently only used with the radiotapnamespace (not with vendor namespaces), but if the undefinedfield 18 is used, the alignment/size is unknown as well. Inthis case, iterator->_next_ns_data isn't initialized (it'sonly set for skipping vendor namespaces), and syzbot pointsout that we later compare against this uninitialized value.Fix this by moving the rejection of unknown radiotap fieldsdown to after the in-namespace lookup, so it will really useiterator->_next_ns_data only for vendor namespaces, even incase undefined fields are present.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23378 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_ife: Fix metalist update behaviorWhenever an ife action replace changes the metalist, instead ofreplacing the old data on the metalist, the current ife code is appendingthe new metadata. Aside from being innapropriate behavior, this may leadto an unbounded addition of metadata to the metalist which might cause anout of bounds error when running the encode op:[ 138.423369][ C1] ==================================================================[ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ife_tlv_meta_encode (net/ife/ife.c:168)[ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ife_out_out_bou/255[ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ife_out_out_bou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full)[ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011[ 138.425800][ C1] Call Trace:[ 138.425804][ C1] [ 138.425808][ C1] dump_stack_lvl (lib/dump_stack.c:122)[ 138.425828][ C1] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)[ 138.425839][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 138.425844][ C1] ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1))[ 138.425853][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168)[ 138.425859][ C1] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597)[ 138.425868][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168)[ 138.425878][ C1] kasan_check_range (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1))[ 138.425884][ C1] __asan_memset (mm/kasan/shadow.c:84 (discriminator 2))[ 138.425889][ C1] ife_tlv_meta_encode (net/ife/ife.c:168)[ 138.425893][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:171)[ 138.425898][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 138.425903][ C1] ife_encode_meta_u16 (net/sched/act_ife.c:57)[ 138.425910][ C1] ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114)[ 138.425916][ C1] ? __asan_memcpy (mm/kasan/shadow.c:105 (discriminator 3))[ 138.425921][ C1] ? __pfx_ife_encode_meta_u16 (net/sched/act_ife.c:45)[ 138.425927][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)[ 138.425931][ C1] tcf_ife_act (net/sched/act_ife.c:847 net/sched/act_ife.c:879)To solve this issue, fix the replace behavior by adding the metalist tothe ife rcu data structure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23388 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check metadata block offset is within rangeSyzkaller reports a "general protection fault in squashfs_copy_data"This is ultimately caused by a corrupted index look-up table, whichproduces a negative metadata block offset.This is subsequently passed to squashfs_copy_data (viasquashfs_read_metadata) where the negative offset causes an out of boundsaccess.The fix is to check that the offset is within range insquashfs_read_metadata. This will trap this and other cases.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23455 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()In DecodeQ931(), the UserUserIE code path reads a 16-bit length fromthe packet, then decrements it by 1 to skip the protocol discriminatorbyte before passing it to DecodeH323_UserInformation(). If the encodedlength is 0, the decrement wraps to -1, which is then passed as alarge value to the decoder, leading to an out-of-bounds read.Add a check to ensure len is positive after the decrement.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31725 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ecm: Fix net_device lifecycle with device_moveThe net_device is allocated during function instance creation andregistered during the bind phase with the gadget device as its sysfsparent. When the function unbinds, the parent device is destroyed, butthe net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directoryUse device_move() to reparent the net_device between the gadget devicetree and /sys/devices/virtual across bind and unbind cycles. During thefinal unbind, calling device_move(NULL) moves the net_device to thevirtual device tree before the gadget device is destroyed. On rebinding,device_move() reparents the device back under the new gadget, ensuringproper sysfs topology and power management ordering.To maintain compatibility with legacy composite drivers (e.g., multi.c),the bound flag is used to indicate whether the network device is sharedand pre-registered during the legacy driver's bind phase.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-41989 Severity: Moderate CVSS3 score: 6.3

Description: Libgcrypt before 1.12.2 sometimes allows a heap-based buffer overflow and denial of service via crafted ECDH ciphertext to gcry_pk_decrypt.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
grub2 > 0-0 (version in image is 2.06-150400.11.72.2).

CVE-2026-43068 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()There's issue as follows:...EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): error count since last fsck: 1EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760...According to the log analysis, blocks are always requested from thecorrupted block group. This may happen as follows:ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return errorext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out;After commit 9008a58e5dce ("ext4: make the bitmap read routines returnreal error codes") merged, Commit 163a203ddb36 ("ext4: mark block groupas corrupt on block bitmap error") is no real solution for allocatingblocks from corrupted block groups. This is because if'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then'ext4_mb_load_buddy()' may return an error. This means that the blockallocation will fail.Therefore, check block group if corrupted when ext4_mb_load_buddy()returns error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43073 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:x86-64: rename misleadingly named '__copy_user_nocache()' functionThis function was a masterclass in bad naming, for various historicalreasons.It claimed to be a non-cached user copy. It is literally _neither_ ofthose things. It's a specialty memory copy routine that usesnon-temporal stores for the destination (but not the source), and thatdoes exception handling for both source and destination accesses.Also note that while it works for unaligned targets, any unaligned parts(whether at beginning or end) will not use non-temporal stores, sinceonly words and quadwords can be non-temporal on x86.The exception handling means that it _can_ be used for user spaceaccesses, but not on its own - it needs all the normal "start user spaceaccess" logic around it.But typically the user space access would be the source, not thenon-temporal destination. That was the original intention of this,where the destination was some fragile persistent memory target thatneeded non-temporal stores in order to catch machine check exceptionssynchronously and deal with them gracefully.Thus that non-descriptive name: one use case was to copy from user spaceinto a non-cached kernel buffer. However, the existing users are a mixof that intended use-case, and a couple of random drivers that just didthis as a performance tweak.Some of those random drivers then actively misused the user copyingversion (with STAC/CLAC and all) to do kernel copies without ever evencaring about the exception handling, _just_ for the non-temporaldestination.Rename it as a first small step to actually make it halfway sane, andchange the prototype to be more normal: it doesn't take a user pointerunless the caller has done the proper conversion, and the argument sizeis the full size_t (it still won't actually copy more than 4GB in onego, but there's also no reason to silently truncate the size argument inthe caller).Finally, use this now sanely named function in the NTB code, whichmis-used a user copy version (with STAC/CLAC and all) of this interfacedespite it not actually being a user copy at all.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43111 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:HID: roccat: fix use-after-free in roccat_report_eventroccat_report_event() iterates over the device->readers list withoutholding the readers_lock. This allows a concurrent roccat_release() toremove and free a reader while it's still being accessed, leading to ause-after-free.Protect the readers list traversal with the readers_lock mutex.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43158 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: fix freemap adjustments when adding xattrs to leaf blocksxfs/592 and xfs/794 both trip this assertion in the leaf block freemapadjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf));Upon enabling quite a lot more debugging code, I narrowed this down tofsstress trying to set a local extended attribute with namelen=3 andvaluelen=71. This results in an entry size of 80 bytes.At the start of xfs_attr3_leaf_add_work, the freemap looks like this:i 0 base 448 size 0 rhs 448 count 46i 1 base 388 size 132 rhs 448 count 46i 2 base 2120 size 4 rhs 448 count 46firstused = 520where "rhs" is the first byte past the end of the leaf entry array.This is inconsistent -- the entries array ends at byte 448, butfreemap[1] says there's free space starting at byte 388!By the end of the function, the freemap is in worse shape:i 0 base 456 size 0 rhs 456 count 47i 1 base 388 size 52 rhs 456 count 47i 2 base 2120 size 4 rhs 456 count 47firstused = 440Important note: 388 is not aligned with the entries array element sizeof 8 bytes.Based on the incorrect freemap, the name area starts at byte 440, whichis below the end of the entries array! That's why the assertiontriggers and the filesystem shuts down.How did we end up here? First, recall from the previous patch that thefreemap array in an xattr leaf block is not intended to be acomprehensive map of all free space in the leaf block. In other words,it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time agoIf we add one xattr, the entries array grows to 384 bytes, andfreemap[0] becomes [base = 384, size = 0]. So far, so good. But if weadd a second xattr, the entries array grows to 392 bytes, and freemap[0]gets pushed up to [base = 392, size = 0]. This is bad, becausefreemap[1] hasn't been updated, and now the entries array and the freespace claim the same space.The fix here is to adjust all freemap entries so that none of themcollide with the entries array. Note that this fix relies on commit2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") andthe previous patch that resets zero length freemap entries to havebase = 0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43187 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: delete attr leaf freemap entries when emptyBack in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.sizeunderflow"), Brian Foster observed that it's possible for a smallfreemap at the end of the end of the xattr entries array to experiencea size underflow when subtracting the space consumed by an expansion ofthe entries array. There are only three freemap entries, which meansthat it is not a complete index of all free space in the leaf block.This code can leave behind a zero-length freemap entry with a nonzerobase. Subsequent setxattr operations can increase the base up to thepoint that it overlaps with another freemap entry. This isn't in and ofitself a problem because the code in _leaf_add that finds free spaceignores any freemap entry with zero size.However, there's another bug in the freemap update code in _leaf_add,which is that it fails to update a freemap entry that begins midwaythrough the xattr entry that was just appended to the array. That canresult in the freemap containing two entries with the same base butdifferent sizes (0 for the "pushed-up" entry, nonzero for the entrythat's actually tracking free space). A subsequent _leaf_add can thenallocate xattr namevalue entries on top of the entries array, leading todata loss. But fixing that is for later.For now, eliminate the possibility of confusion by zeroing out the baseof any freemap entry that has zero size. Because the freemap is notintended to be a complete index of free space, a subsequent failure tofind any free space for a new xattr will trigger block compaction, whichregenerates the freemap.It looks like this bug has been in the codebase for quite a long time.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43249 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:9p/xen: protect xen_9pfs_front_free against concurrent callsThe xenwatch thread can race with other back-end change notificationsand call xen_9pfs_front_free() twice, hitting the observed generalprotection fault due to a double-free. Guard the teardown path so onlyone caller can release the front-end state at a time, preventing thecrash.This is a fix for the following double-free:[ 27.052347] Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI[ 27.052357] CPU: 0 UID: 0 PID: 32 Comm: xenwatch Not tainted 6.18.0-02087-g51ab33fc0a8b-dirty #60 PREEMPT(none)[ 27.052363] RIP: e030:xen_9pfs_front_free+0x1d/0x150[ 27.052368] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 41 55 41 54 55 48 89 fd 48 c7 c7 48 d0 92 85 53 e8 cb cb 05 00 48 8b 45 08 48 8b 55 00 <48> 3b 28 0f 85 f9 28 35 fe 48 3b 6a 08 0f 85 ef 28 35 fe 48 89 42[ 27.052377] RSP: e02b:ffffc9004016fdd0 EFLAGS: 00010246[ 27.052381] RAX: 6b6b6b6b6b6b6b6b RBX: ffff88800d66e400 RCX: 0000000000000000[ 27.052385] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000000 RDI: 0000000000000000[ 27.052389] RBP: ffff88800a887040 R08: 0000000000000000 R09: 0000000000000000[ 27.052393] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888009e46b68[ 27.052397] R13: 0000000000000200 R14: 0000000000000000 R15: ffff88800a887040[ 27.052404] FS: 0000000000000000(0000) GS:ffff88808ca57000(0000) knlGS:0000000000000000[ 27.052408] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033[ 27.052412] CR2: 00007f9714004360 CR3: 0000000004834000 CR4: 0000000000050660[ 27.052418] Call Trace:[ 27.052420] [ 27.052422] xen_9pfs_front_changed+0x5d5/0x720[ 27.052426] ? xenbus_otherend_changed+0x72/0x140[ 27.052430] ? __pfx_xenwatch_thread+0x10/0x10[ 27.052434] xenwatch_thread+0x94/0x1c0[ 27.052438] ? __pfx_autoremove_wake_function+0x10/0x10[ 27.052442] kthread+0xf8/0x240[ 27.052445] ? __pfx_kthread+0x10/0x10[ 27.052449] ? __pfx_kthread+0x10/0x10[ 27.052452] ret_from_fork+0x16b/0x1a0[ 27.052456] ? __pfx_kthread+0x10/0x10[ 27.052459] ret_from_fork_asm+0x1a/0x30[ 27.052463] [ 27.052465] Modules linked in:[ 27.052471] ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43250 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:usb: chipidea: udc: fix DMA and SG cleanup in _ep_nuke()The ChipIdea UDC driver can encounter "not page aligned sg buffer"errors when a USB device is reconnected after being disconnectedduring an active transfer. This occurs because _ep_nuke() returnsrequests to the gadget layer without properly unmapping DMA buffersor cleaning up scatter-gather bounce buffers.Root cause:When a disconnect happens during a multi-segment DMA transfer, therequest's num_mapped_sgs field and sgt.sgl pointer remain set withstale values. The request is returned to the gadget driver with status-ESHUTDOWN but still has active DMA state. If the gadget driver reusesthis request on reconnect without reinitializing it, the stale DMAstate causes _hardware_enqueue() to skip DMA mapping (seeing non-zeronum_mapped_sgs) and attempt to use freed/invalid DMA addresses,leading to alignment errors and potential memory corruption.The normal completion path via _hardware_dequeue() properly callsusb_gadget_unmap_request_by_dev() and sglist_do_debounce() beforereturning the request. The _ep_nuke() path must do the same cleanupto ensure requests are returned in a clean, reusable state.Fix:Add DMA unmapping and bounce buffer cleanup to _ep_nuke() to mirrorthe cleanup sequence in _hardware_dequeue():- Call usb_gadget_unmap_request_by_dev() if num_mapped_sgs is set- Call sglist_do_debounce() with copy=false if bounce buffer existsThis ensures that when requests are returned due to endpoint shutdown,they don't retain stale DMA mappings. The 'false' parameter tosglist_do_debounce() prevents copying data back (appropriate forshutdown path where transfer was aborted).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45843 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:slip: bound decode() reads against the compressed packet lengthslhc_uncompress() parses a VJ-compressed TCP header by advancing apointer through the packet via decode() and pull16(). Neither helperbounds-checks against isize, and decode() masks its return with& 0xffff so it can never return the -1 that callers test for -- thoseerror paths are dead code.A short compressed frame whose change byte requests optional fieldslets decode() read past the end of the packet. The over-read bytesare folded into the cached cstate and reflected into subsequentreconstructed packets.Make decode() and pull16() take the packet end pointer and return -1when exhausted. Add a bounds check before the TCP-checksum read.The existing == -1 tests now do what they were always meant to.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45885 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:power: supply: cpcap-battery: Fix use-after-free in power_supply_changed()Using the `devm_` variant for requesting IRQ _before_ the `devm_`variant for allocating/registering the `power_supply` handle, means thatthe `power_supply` handle will be deallocated/unregistered _before_ theinterrupt handler (since `devm_` naturally deallocates in reverseallocation order). This means that during removal, there is a racecondition where an interrupt can fire just _after_ the `power_supply`handle has been freed, *but* just _before_ the correspondingunregistration of the IRQ handler has run.This will lead to the IRQ handler calling `power_supply_changed()` witha freed `power_supply` handle. Which usually crashes the system orotherwise silently corrupts the memory...Note that there is a similar situation which can also happen during`probe()`; the possibility of an interrupt firing _before_ registeringthe `power_supply` handle. This would then lead to the nasty situationof using the `power_supply` handle *uninitialized* in`power_supply_changed()`.Fix this racy use-after-free by making sure the IRQ is requested _after_the registration of the `power_supply` handle.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45894 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Clear Present bit before tearing down PASID entryThe Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64bytes). When tearing down an entry, the current implementation zeros theentire 64-byte structure immediately using multiple 64-bit writes.Since the IOMMU hardware may fetch these 64 bytes using multipleinternal transactions (e.g., four 128-bit bursts), updating or zeroingthe entire entry while it is active (P=1) risks a "torn" read. If ahardware fetch occurs simultaneously with the CPU zeroing the entry, thehardware could observe an inconsistent state, leading to unpredictablebehavior or spurious faults.Follow the "Guidance to Software for Invalidations" in the VT-d spec(Section 6.5.3.3) by implementing the recommended ownership handshake:1. Clear only the 'Present' (P) bit of the PASID entry.2. Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding.3. Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references.4. Only after the flushes are complete, zero out the remaining fields of the PASID entry.Also, add a dma_wmb() in pasid_set_present() to ensure that all otherfields of the PASID entry are visible to the hardware before the Presentbit is set.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45902 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:power: supply: bq256xx: Fix use-after-free in power_supply_changed()Using the `devm_` variant for requesting IRQ _before_ the `devm_`variant for allocating/registering the `power_supply` handle, means thatthe `power_supply` handle will be deallocated/unregistered _before_ theinterrupt handler (since `devm_` naturally deallocates in reverseallocation order). This means that during removal, there is a racecondition where an interrupt can fire just _after_ the `power_supply`handle has been freed, *but* just _before_ the correspondingunregistration of the IRQ handler has run.This will lead to the IRQ handler calling `power_supply_changed()` witha freed `power_supply` handle. Which usually crashes the system orotherwise silently corrupts the memory...Note that there is a similar situation which can also happen during`probe()`; the possibility of an interrupt firing _before_ registeringthe `power_supply` handle. This would then lead to the nasty situationof using the `power_supply` handle *uninitialized* in`power_supply_changed()`.Fix this racy use-after-free by making sure the IRQ is requested _after_the registration of the `power_supply` handle.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-46151 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:usb: usblp: fix heap leak in IEEE 1284 device ID via short responseusblp_ctrl_msg() collapses the usb_control_msg() return value to0/-errno, discarding the actual number of bytes transferred. A brokenprinter can complete the GET_DEVICE_ID control transfer short and thedriver has no way to know.usblp_cache_device_id_string() reads the 2-byte big-endian length prefixfrom the response and trusts it (clamped only to the buffer bounds).The buffer is kmalloc(1024) at probe time. A device that sends exactlytwo bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leavesdevice_id_string[2..1022] holding stale kmalloc heap.That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf("%s", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device.Fix this up by just zapping the buffer with zeros before each requestsent to the device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-38469 Severity: Moderate CVSS3 score: 6.2

Description: A vulnerability was found in Avahi, where a reachable assertion exists in avahi_dns_packet_append_record.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.26.1).

CVE-2023-38471 Severity: Moderate CVSS3 score: 6.2

Description: A vulnerability was found in Avahi. A reachable assertion exists in the dbus_set_host_name function.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.26.1).

CVE-2023-38472 Severity: Moderate CVSS3 score: 6.2

Description: A vulnerability was found in Avahi. A reachable assertion exists in the avahi_rdata_parse() function.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.26.1).

CVE-2023-52491 Severity: Moderate CVSS3 score: 6.2

Description: In the Linux kernel, the following vulnerability has been resolved:media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_runIn mtk_jpeg_probe, &jpeg->job_timeout_work is bound withmtk_jpeg_job_timeout_work.In mtk_jpeg_dec_device_run, if error happens inmtk_jpeg_set_dec_dst, it will finally start the worker whilemark the job as finished by invoking v4l2_m2m_job_finish.There are two methods to trigger the bug. If we remove themodule, it which will call mtk_jpeg_remove to make cleanup.The possible sequence is as follows, which will cause ause-after-free bug.CPU0 CPU1mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_workmtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //useIf we close the file descriptor, which will call mtk_jpeg_release,it will have a similar sequence.Fix this bug by starting timeout worker only if started jpegdec workersuccessfully. Then v4l2_m2m_job_finish will only be called ineither mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53484 Severity: Moderate CVSS3 score: 6.2

Description: In the Linux kernel, the following vulnerability has been resolved:lib: cpu_rmap: Avoid use after free on rmap->obj array entriesWhen calling irq_set_affinity_notifier() with NULL at the notifyargument, it will cause freeing of the glue pointer in thecorresponding array entry but will leave the pointer in the array. Asubsequent call to free_irq_cpu_rmap() will try to free this entry againleading to possible use after free.Fix that by setting NULL to the array entry and checking that we havenon-zero at the array entry when iterating over the array infree_irq_cpu_rmap().The current code does not suffer from this since there are no caseswhere irq_set_affinity_notifier(irq, NULL) (note the NULL passed for thenotify arg) is called, followed by a call to free_irq_cpu_rmap() so wedon't hit and issue. Subsequent patches in this series excersize thisflow, hence the required fix.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54169 Severity: Moderate CVSS3 score: 6.2

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: fix memory leak in mlx5e_ptp_openWhen kvzalloc_node or kvzalloc failed in mlx5e_ptp_open, the memorypointed by "c" or "cparams" is not freed, which can lead to a memoryleak. Fix by freeing the array in the error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54265 Severity: Moderate CVSS3 score: 6.2

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix an uninit variable access bug in __ip6_make_skb()Syzbot reported a bug as following:=====================================================BUG: KMSAN: uninit-value in arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline]BUG: KMSAN: uninit-value in arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline]BUG: KMSAN: uninit-value in atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline]BUG: KMSAN: uninit-value in __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline] arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline] atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline] __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 ip6_finish_skb include/net/ipv6.h:1122 [inline] ip6_push_pending_frames+0x10e/0x550 net/ipv6/ip6_output.c:1987 rawv6_push_pending_frames+0xb12/0xb90 net/ipv6/raw.c:579 rawv6_sendmsg+0x297e/0x2e60 net/ipv6/raw.c:922 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 alloc_skb include/linux/skbuff.h:1270 [inline] __ip6_append_data+0x51c1/0x6bb0 net/ipv6/ip6_output.c:1684 ip6_append_data+0x411/0x580 net/ipv6/ip6_output.c:1854 rawv6_sendmsg+0x2882/0x2e60 net/ipv6/raw.c:915 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdIt is because icmp6hdr does not in skb linear region under the scenarioof SOCK_RAW socket. Access icmp6_hdr(skb)->icmp6_type directly willtrigger the uninit variable access bug.Use a local variable icmp6_type to carry the correct value in differentscenarios.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-6915 Severity: Moderate CVSS3 score: 6.2

Description: A Null pointer dereference problem was found in ida_free in lib/idr.c in the Linux Kernel. This issue may allow an attacker using this library to cause a denial of service problem due to a missing check at a function return.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38428 Severity: Moderate CVSS3 score: 6.2

Description: url.c in GNU Wget through 1.24.5 mishandles semicolons in the userinfo subcomponent of a URI, and thus there may be insecure behavior in which data that was supposed to be in the userinfo subcomponent is misinterpreted to be part of the host subcomponent.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
wget > 0-0 (version in image is 1.20.3-150000.3.29.1).

CVE-2024-45490 Severity: Moderate CVSS3 score: 6.2

Description: An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.37.1).

CVE-2024-45491 Severity: Moderate CVSS3 score: 6.2

Description: An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.37.1).

CVE-2024-45492 Severity: Moderate CVSS3 score: 6.2

Description: An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for m_groupSize on 32-bit platforms (where UINT_MAX equals SIZE_MAX).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.37.1).

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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-40909 Severity: Moderate CVSS3 score: 6.2

Description: Perl threads have a working directory race condition where file operations may target unintended paths.If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running. This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit.The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
perl > 0-0 (version in image is 5.26.1-150300.17.20.1).

CVE-2026-13757 Severity: Moderate CVSS3 score: 6.2

Description: A flaw was found in p11-kit. The RPC message attribute parsing functions p11_rpc_message_get_attribute() and p11_rpc_message_get_attribute_array_value() form a mutually-recursive call chain with no recursion depth limit when processing nested CKA_WRAP_TEMPLATE, CKA_UNWRAP_TEMPLATE, and CKA_DERIVE_TEMPLATE attributes. An unauthenticated attacker with local access to the p11-kit RPC Unix domain socket can send a specially crafted request with deeply nested template attributes, causing stack exhaustion and crashing the p11-kit server process and its dependent services.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libp11-kit0 > 0-0 (version in image is 0.23.22-150400.1.10).

CVE-2026-23679 Severity: Moderate CVSS3 score: 6.2

Description: libusb before version 1.0.30 contains a NULL pointer dereference vulnerability that allows attackers to crash applications by supplying a malformed USB configuration descriptor where an interface claims bNumEndpoints greater than zero but is followed by a class-specific descriptor whose bLength exceeds the remaining buffer size, causing parse_interface() to return early without allocating the endpoint array. Attackers can exploit this flaw through libusb_get_active_config_descriptor or libusb_get_config_descriptor by providing crafted descriptors via virtualized USB passthrough, file-based descriptor parsing, or network sources, causing any application iterating over endpoints to dereference a NULL endpoint pointer and crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libusb-1_0-0 > 0-0 (version in image is 1.0.24-150400.3.3.1).

CVE-2026-43491 Severity: Moderate CVSS3 score: 6.2

Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: ns: Limit the maximum server registration per nodeCurrent code does no bound checking on the number of servers added pernode. A malicious client can flood NEW_SERVER messages and exhaust memory.Fix this issue by limiting the maximum number of server registrations to256 per node. If the NEW_SERVER message is received for an old port, thendon't restrict it as it will get replaced. While at it, also rate limitthe error messages in the failure path of qrtr_ns_worker().Note that the limit of 256 is chosen based on the current platformrequirements. If requirement changes in the future, this limit can beincreased.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-46098 Severity: Moderate CVSS3 score: 6.2

Description: In the Linux kernel, the following vulnerability has been resolved:net: caif: clear client service pointer on teardown`caif_connect()` can tear down an existing client after remote shutdown bycalling `caif_disconnect_client()` followed by `caif_free_client()`.`caif_free_client()` releases the service layer referenced by`adap_layer->dn`, but leaves that pointer stale.When the socket is later destroyed, `caif_sock_destructor()` calls`caif_free_client()` again and dereferences the freed service pointer.Clear the client/service links before releasing the service object sorepeated teardown becomes harmless.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53040 Severity: Moderate CVSS3 score: 6.2

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: validate bg_bits during freefrag scan[BUG]A crafted filesystem can trigger an out-of-bounds bitmap walk whenOCFS2_IOC_INFO is issued with OCFS2_INFO_FL_NON_COHERENT.BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline]BUG: KASAN: use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]BUG: KASAN: use-after-free in test_bit_le include/asm-generic/bitops/le.h:21 [inline]BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline]BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline]BUG: KASAN: use-after-free in ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline]BUG: KASAN: use-after-free in ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754Read of size 8 at addr ffff888031bce000 by task syz.0.636/1435Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 [inline] kasan_check_range+0x11c/0x200 mm/kasan/generic.c:200 __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] test_bit_le include/asm-generic/bitops/le.h:21 [inline] ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 ocfs2_info_handle+0x18d/0x2a0 fs/ocfs2/ioctl.c:828 ocfs2_ioctl+0x632/0x6e0 fs/ocfs2/ioctl.c:913 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+0x197/0x1e0 fs/ioctl.c:583 ...[CAUSE]ocfs2_info_freefrag_scan_chain() uses on-disk bg_bits directly as thebitmap scan limit. The coherent path reads group descriptors throughocfs2_read_group_descriptor(), which validates the descriptor beforeuse. The non-coherent path uses ocfs2_read_blocks_sync() instead andskips that validation, so an impossible bg_bits value can drive thebitmap walk past the end of the block.[FIX]Compute the bitmap capacity from the filesystem format withocfs2_group_bitmap_size(), report descriptors whose bg_bits exceedsthat limit, and clamp the scan to the computed capacity. This keeps thefreefrag report going while avoiding reads beyond the buffer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48980 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing()The SJA1105 family has 45 L2 policing table entries(SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110(SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure butaccounting for the difference in port count (5 in SJA1105 vs 10 inSJA1110) does not fully explain the difference. Rather, the SJA1110 alsohas L2 ingress policers for multicast traffic. If a packet is classifiedas multicast, it will be processed by the policer index 99 + SRCPORT.The sja1105_init_l2_policing() function initializes all L2 policers suchthat they don't interfere with normal packet reception by default. To havea common code between SJA1105 and SJA1110, the index of the multicastpolicer for the port is calculated because it's an index that is out ofbounds for SJA1105 but in bounds for SJA1110, and a bounds check isperformed.The code fails to do the proper thing when determining what to do with themulticast policer of port 0 on SJA1105 (ds->num_ports = 5). The "mcast"index will be equal to 45, which is also equal totable->ops->max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passesthrough the check. But at the same time, SJA1105 doesn't have multicastpolicers. So the code programs the SHARINDX field of an out-of-boundselement in the L2 Policing table of the static config.The comparison between index 45 and 45 entries should have determined thecode to not access this policer index on SJA1105, since its memory wasn'teven allocated.With enough bad luck, the out-of-bounds write could even overwrite othervalid kernel data, but in this case, the issue was detected using KASAN.Kernel log:sja1105 spi5.0: Probed switch chip: SJA1105Q==================================================================BUG: KASAN: slab-out-of-bounds in sja1105_setup+0x1cbc/0x2340Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8...Workqueue: events_unbound deferred_probe_work_funcCall trace:...sja1105_setup+0x1cbc/0x2340dsa_register_switch+0x1284/0x18d0sja1105_probe+0x748/0x840...Allocated by task 8:...sja1105_setup+0x1bcc/0x2340dsa_register_switch+0x1284/0x18d0sja1105_probe+0x748/0x840...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50400 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:staging: greybus: audio_helper: remove unused and wrong debugfs usageIn the greybus audio_helper code, the debugfs file for the dapm has thepotential to be removed and memory will be leaked. There is also thevery real potential for this code to remove ALL debugfs entries from thesystem, and it seems like this is what will really happen if this codeever runs. This all is very wrong as the greybus audio driver did notcreate this debugfs file, the sound core did and controls the lifespanof it.So remove all of the debugfs logic from the audio_helper code as there'sno way it could be correct. If this really is needed, it can come backwith a fixup for the incorrect usage of the debugfs_lookup() call whichis what caused this to be noticed at all.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53220 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:media: az6007: Fix null-ptr-deref in az6007_i2c_xfer()In az6007_i2c_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach az6007_i2c_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53456 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla4xxx: Add length check when parsing nlattrsThere are three places that qla4xxx parses nlattrs: - qla4xxx_set_chap_entry() - qla4xxx_iface_set_param() - qla4xxx_sysfs_ddb_set_param()and each of them directly converts the nlattr to specific pointer ofstructure without length checking. This could be dangerous as thoseattributes are not validated and a malformed nlattr (e.g., length 0) couldresult in an OOB read that leaks heap dirty data.Add the nla_len check before accessing the nlattr data and return EINVAL ifthe length check fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53624 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_fq: fix integer overflow of "credit"if sch_fq is configured with "initial quantum" having values greater thanINT_MAX, the first assignment of "credit" does signed integer overflow toa very negative value.In this situation, the syzkaller script provided by Cristoph triggers theCPU soft-lockup warning even with few sockets. It's not an infinite loop,but "credit" wasn't probably meant to be minus 2Gb for each new flow.Capping "initial quantum" to INT_MAX proved to fix the issue.v2: validation of "initial quantum" is done in fq_policy, instead of open coding in fq_change() _ suggested by Jakub Kicinski

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53635 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: fix wrong ct->timeout value(struct nf_conn)->timeout is an interval before the conntrackconfirmed. After confirmed, it becomes a timestamp.It is observed that timeout of an unconfirmed conntrack:- Set by calling ctnetlink_change_timeout(). As a result, `nfct_time_stamp` was wrongly added to `ct->timeout` twice.- Get by calling ctnetlink_dump_timeout(). As a result, `nfct_time_stamp` was wrongly subtracted.Call Trace: dump_stack_lvl ctnetlink_dump_timeout __ctnetlink_glue_build ctnetlink_glue_build __nfqnl_enqueue_packet nf_queue nf_hook_slow ip_mc_output ? __pfx_ip_finish_output ip_send_skb ? __pfx_dst_output udp_send_skb udp_sendmsg ? __pfx_ip_generic_getfrag sock_sendmsgSeparate the 2 cases in:- Setting `ct->timeout` in __nf_ct_set_timeout().- Getting `ct->timeout` in ctnetlink_dump_timeout().Pablo appends:Update ctnetlink to set up the timeout _after_ the IPS_CONFIRMED flag isset on, otherwise conntrack creation via ctnetlink breaks.Note that the problem described in this patch occurs since theintroduction of the nfnetlink_queue conntrack support, select asufficiently old Fixes: tag for -stable kernel to pick up this fix.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54182 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to check readonly condition correctlyWith below case, it can mount multi-device image w/ rw option, howeverone of secondary device is set as ro, later update will cause panic, solet's introduce f2fs_dev_is_readonly(), and check multi-devices rw statusin f2fs_remount() w/ it in order to avoid such inconsistent mount status.mkfs.f2fs -c /dev/zram1 /dev/zram0 -fblockdev --setro /dev/zram1mount -t f2fs dev/zram0 /mnt/f2fsmount: /mnt/f2fs: WARNING: source write-protected, mounted read-only.mount -t f2fs -o remount,rw mnt/f2fsdd if=/dev/zero of=/mnt/f2fs/file bs=1M count=8192kernel BUG at fs/f2fs/inline.c:258!RIP: 0010:f2fs_write_inline_data+0x23e/0x2d0 [f2fs]Call Trace: f2fs_write_single_data_page+0x26b/0x9f0 [f2fs] f2fs_write_cache_pages+0x389/0xa60 [f2fs] __f2fs_write_data_pages+0x26b/0x2d0 [f2fs] f2fs_write_data_pages+0x2e/0x40 [f2fs] do_writepages+0xd3/0x1b0 __writeback_single_inode+0x5b/0x420 writeback_sb_inodes+0x236/0x5a0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x2a3/0x490 wb_do_writeback+0x2b2/0x330 wb_workfn+0x6a/0x260 process_one_work+0x270/0x5e0 worker_thread+0x52/0x3e0 kthread+0xf4/0x120 ret_from_fork+0x29/0x50

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54232 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:m68k: Only force 030 bus error if PC not in exception table__get_kernel_nofault() does copy data in supervisor mode whenforcing a task backtrace log through /proc/sysrq_trigger.This is expected cause a bus error exception on e.g. NULLpointer dereferencing when logging a kernel task has noworkqueue associated. This bus error ought to be ignored.Our 030 bus error handler is ill equipped to deal with this:Whenever ssw indicates a kernel mode access on a data fault,we don't even attempt to handle the fault and instead alwayssend a SEGV signal (or panic). As a result, the checkfor exception handling at the fault PC (buried insend_sig_fault() which gets called from do_page_fault()eventually) is never used.In contrast, both 040 and 060 access error handlers do notcare whether a fault happened on supervisor mode access,and will call do_page_fault() on those, ultimately honoringthe exception table.Add a check in bus_error030 to call do_page_fault() in casewe do have an entry for the fault PC in our exception table.I had attempted a fix for this earlier in 2019 that did relyon testing pagefault_disabled() (see link below) to achievethe same thing, but this patch should be more generic.Tested on 030 Atari Falcon.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54312 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:samples/bpf: Fix buffer overflow in tcp_baserttUsing sizeof(nv) or strlen(nv)+1 is correct.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54316 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:refscale: Fix uninitalized use of wait_queue_head_tRunning the refscale test occasionally crashes the kernel with thefollowing error:[ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8[ 8569.952900] #PF: supervisor read access in kernel mode[ 8569.952902] #PF: error_code(0x0000) - not-present page[ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0[ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI[ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021[ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190 :[ 8569.952940] Call Trace:[ 8569.952941] [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale][ 8569.952959] kthread+0x10e/0x130[ 8569.952966] ret_from_fork+0x1f/0x30[ 8569.952973] The likely cause is that init_waitqueue_head() is called after the call tothe torture_create_kthread() function that creates the ref_scale_readerkthread. Although this init_waitqueue_head() call will very likelycomplete before this kthread is created and starts running, it ispossible that the calling kthread will be delayed between the calls totorture_create_kthread() and init_waitqueue_head(). In this case, thenew kthread will use the waitqueue head before it is properly initialized,which is not good for the kernel's health and well-being.The above crash happened here: static inline void __add_wait_queue(...) { : if (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash hereThe offset of flags from list_head entry in wait_queue_entry is-0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_taskstructure is zero initialized, the instruction will try to access address0xffffffffffffffe8, which is exactly the fault address listed above.This commit therefore invokes init_waitqueue_head() before creatingthe kthread.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-6606 Severity: Moderate CVSS3 score: 6.1

Description: An out-of-bounds read vulnerability was found in smbCalcSize in fs/smb/client/netmisc.c in the Linux Kernel. This issue could allow a local attacker to crash the system or leak internal kernel information.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-0607 Severity: Moderate CVSS3 score: 6.1

Description: A flaw was found in the Netfilter subsystem in the Linux kernel. The issue is in the nft_byteorder_eval() function, where the code iterates through a loop and writes to the `dst` array. On each iteration, 8 bytes are written, but `dst` is an array of u32, so each element only has space for 4 bytes. That means every iteration overwrites part of the previous element corrupting this array of u32. This flaw allows a local user to cause a denial of service or potentially break NetFilter functionality.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-10524 Severity: Moderate CVSS3 score: 6.1

Description: Applications that use Wget to access a remote resource using shorthand URLs and pass arbitrary user credentials in the URL are vulnerable. In these cases attackers can enter crafted credentials which will cause Wget to access an arbitrary host.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
wget > 0-0 (version in image is 1.20.3-150000.3.29.1).

CVE-2024-26635 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:llc: Drop support for ETH_P_TR_802_2.syzbot reported an uninit-value bug below. [0]llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2(0x0011), and syzbot abused the latter to trigger the bug. write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)llc_conn_handler() initialises local variables {saddr,daddr}.macbased on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passesthem to __llc_lookup().However, the initialisation is done only when skb->protocol ishtons(ETH_P_802_2), otherwise, __llc_lookup_established() and__llc_lookup_listener() will read garbage.The missing initialisation existed prior to commit 211ed865108e("net: delete all instances of special processing for token ring").It removed the part to kick out the token ring stuff but forgot toclose the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().Let's remove llc_tr_packet_type and complete the deprecation.[0]:BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6bLocal variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26641 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].Call pskb_inet_may_pull() to fix this, and initialize ipv6hvariable after this call as it can change skb->head.[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+0x7df/0x1e50 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+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bCPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-34064 Severity: Moderate CVSS3 score: 6.1

Description: Jinja is an extensible templating engine. The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe. This vulnerability is fixed in 3.1.4.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-Jinja2 > 0-0 (version in image is 3.1.2-150400.12.14.1).

CVE-2024-36025 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix off by one in qla_edif_app_getstats()The app_reply->elem[] array is allocated earlier in this function and ithas app_req.num_ports elements. Thus this > comparison needs to be >= toprevent memory corruption.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36960 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix invalid reads in fence signaled eventsCorrectly set the length of the drm_event to the size of the structurethat's actually used.The length of the drm_event was set to the parent structure instead ofto the drm_vmw_event_fence which is supposed to be read. drm_readuses the length parameter to copy the event to the user space thusresuling in oob reads.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-37354 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix crash on racing fsync and size-extending write into preallocWe have been seeing crashes on duplicate keys inbtrfs_set_item_key_safe(): BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.c:2620! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]With the following stack trace: #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4) #1 btrfs_drop_extents (fs/btrfs/file.c:411:4) #2 log_one_extent (fs/btrfs/tree-log.c:4732:9) #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9) #4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9) #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8) #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8) #7 btrfs_sync_file (fs/btrfs/file.c:1933:8) #8 vfs_fsync_range (fs/sync.c:188:9) #9 vfs_fsync (fs/sync.c:202:9) #10 do_fsync (fs/sync.c:212:9) #11 __do_sys_fdatasync (fs/sync.c:225:9) #12 __se_sys_fdatasync (fs/sync.c:223:1) #13 __x64_sys_fdatasync (fs/sync.c:223:1) #14 do_syscall_x64 (arch/x86/entry/common.c:52:14) #15 do_syscall_64 (arch/x86/entry/common.c:83:7) #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)So we're logging a changed extent from fsync, which is splitting anextent in the log tree. But this split part already exists in the tree,triggering the BUG().This is the state of the log tree at the time of the crash, dumped withdrgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)to get more details than btrfs_print_leaf() gives us: >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"]) leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610 leaf 33439744 flags 0x100000000000000 fs uuid e5bd3946-400c-4223-8923-190ef1f18677 chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160 generation 7 transid 9 size 8192 nbytes 8473563889606862198 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 204 flags 0x10(PREALLOC) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417704.983333333 (2024-05-22 15:41:44) mtime 1716417704.983333333 (2024-05-22 15:41:44) otime 17592186044416.000000000 (559444-03-08 01:40:16) item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13 index 195 namelen 3 name: 193 item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37 location key (0 UNKNOWN.0 0) type XATTR transid 7 data_len 1 name_len 6 name: user.a data a item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53 generation 9 type 1 (regular) extent data disk byte 303144960 nr 12288 extent data offset 0 nr 4096 ram 12288 extent compression 0 (none) item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 4096 nr 8192 item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 8192 nr 4096 ...So the real problem happened earlier: notice that items 4 (4k-12k) and 5(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size anditem 5 starts at i_size.Here is the state of ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38552 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential index out of bounds in color transformation functionFixes index out of bounds issue in the color transformation function.The issue could occur when the index 'i' exceeds the number of transferfunction points (TRANSFER_FUNC_POINTS).The fix adds a check to ensure 'i' is within bounds before accessing thetransfer function points. If 'i' is out of bounds, an error message islogged and the function returns false to indicate an error.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38594 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: move the EST lock to struct stmmac_privReinitialize the whole EST structure would also reset the mutexlock which is embedded in the EST structure, and then triggerthe following warning. To address this, move the lock to structstmmac_priv. We also need to reacquire the mutex lock when doingthis initialization.DEBUG_LOCKS_WARN_ON(lock->magic != lock)WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068 Modules linked in: CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mutex_lock+0xd84/0x1068 lr : __mutex_lock+0xd84/0x1068 sp : ffffffc0864e3570 x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003 x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000 x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8 x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698 x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027 x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: __mutex_lock+0xd84/0x1068 mutex_lock_nested+0x28/0x34 tc_setup_taprio+0x118/0x68c stmmac_setup_tc+0x50/0xf0 taprio_change+0x868/0xc9c

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-39487 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()In function bond_option_arp_ip_targets_set(), if newval->string is anempty string, newval->string+1 will point to the byte after thestring, causing an out-of-bound read.BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b---[ end trace ]---Fix it by adding a check of string length before using it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-39505 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/komeda: check for error-valued pointerkomeda_pipeline_get_state() may return an error-valued pointer, thuscheck the pointer for negative or null value before dereferencing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42096 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:x86: stop playing stack games in profile_pc()The 'profile_pc()' function is used for timer-based profiling, whichisn't really all that relevant any more to begin with, but it also endsup making assumptions based on the stack layout that aren't necessarilyvalid.Basically, the code tries to account the time spent in spinlocks to thecaller rather than the spinlock, and while I support that as a concept,it's not worth the code complexity or the KASAN warnings when no seriousprofiling is done using timers anyway these days.And the code really does depend on stack layout that is only true in thesimplest of cases. We've lost the comment at some point (I think whenthe 32-bit and 64-bit code was unified), but it used to say: Assume the lock function has either no stack frame or a copy of eflags from PUSHF.which explains why it just blindly loads a word or two straight off thestack pointer and then takes a minimal look at the values to just checkif they might be eflags or the return pc: Eflags always has bits 22 and up cleared unlike kernel addressesbut that basic stack layout assumption assumes that there isn't any lockdebugging etc going on that would complicate the code and cause a stackframe.It causes KASAN unhappiness reported for years by syzkaller [1] andothers [2].With no real practical reason for this any more, just remove the code.Just for historical interest, here's some background commits relating tothis code from 2006: 0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64")and a code unification from 2009: ef4512882dbe ("x86: time_32/64.c unify profile_pc")but the basics of this thing actually goes back to before the git tree.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42104 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: add missing check for inode numbers on directory entriesSyzbot reported that mounting and unmounting a specific pattern ofcorrupted nilfs2 filesystem images causes a use-after-free of metadatafile inodes, which triggers a kernel bug in lru_add_fn().As Jan Kara pointed out, this is because the link count of a metadata filegets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),tries to delete that inode (ifile inode in this case).The inconsistency occurs because directories containing the inode numbersof these metadata files that should not be visible in the namespace areread without checking.Fix this issue by treating the inode numbers of these internal files aserrors in the sanity check helper when reading directory folios/pages.Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layeranalysis.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42105 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix inode number range checksPatch series "nilfs2: fix potential issues related to reserved inodes".This series fixes one use-after-free issue reported by syzbot, caused bynilfs2's internal inode being exposed in the namespace on a corruptedfilesystem, and a couple of flaws that cause problems if the startingnumber of non-reserved inodes written in the on-disk super block isintentionally (or corruptly) changed from its default value. This patch (of 3):In the current implementation of nilfs2, "nilfs->ns_first_ino", whichgives the first non-reserved inode number, is read from the superblock,but its lower limit is not checked.As a result, if a number that overlaps with the inode number range ofreserved inodes such as the root directory or metadata files is set in thesuper block parameter, the inode number test macros (NILFS_MDT_INODE andNILFS_VALID_INODE) will not function properly.In addition, these test macros use left bit-shift calculations using withthe inode number as the shift count via the BIT macro, but the result of ashift calculation that exceeds the bit width of an integer is undefined inthe C specification, so if "ns_first_ino" is set to a large value otherthan the default value NILFS_USER_INO (=11), the macros may potentiallymalfunction depending on the environment.Fix these issues by checking the lower bound of "nilfs->ns_first_ino" andby preventing bit shifts equal to or greater than the NILFS_USER_INOconstant in the inode number test macros.Also, change the type of "ns_first_ino" from signed integer to unsignedinteger to avoid the need for type casting in comparisons such as thelower bound check introduced this time.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42259 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gem: Fix Virtual Memory mapping boundaries calculationCalculating the size of the mapped area as the lesser valuebetween the requested size and the actual size does not considerthe partial mapping offset. This can cause page fault access.Fix the calculation of the starting and ending addresses, thetotal size is now deduced from the difference between the end andstart addresses.Additionally, the calculations have been rewritten in a clearerand more understandable form.[Joonas: Add Requires: tag]Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset")(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53052 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/rw: fix missing NOWAIT check for O_DIRECT start writeWhen io_uring starts a write, it'll call kiocb_start_write() to bump thesuper block rwsem, preventing any freezes from happening while thatwrite is in-flight. The freeze side will grab that rwsem for writing,excluding any new writers from happening and waiting for existing writesto finish. But io_uring unconditionally uses kiocb_start_write(), whichwill block if someone is currently attempting to freeze the mount point.This causes a deadlock where freeze is waiting for previous writes tocomplete, but the previous writes cannot complete, as the task that issupposed to complete them is blocked waiting on starting a new write.This results in the following stuck trace showing that dependency withthe write blocked starting a new write:task:fio state:D stack:0 pid:886 tgid:886 ppid:876Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963with the attempting freezer stuck trying to grab the rwsem:task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt ablocking grab of the super block rwsem if it isn't set. For normal issuewhere IOCB_NOWAIT would always be set, this returns -EAGAIN which willhave io_uring core issue a blocking attempt of the write. That will inturn also get completions run, ensuring forward progress.Since freezing requires CAP_SYS_ADMIN in the first place, this isn'tsomething that can be triggered by a regular user.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53099 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check validity of link->type in bpf_link_show_fdinfo()If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessingbpf_link_type_strs[link->type] may result in an out-of-bounds access.To spot such missed invocations early in the future, checking thevalidity of link->type in bpf_link_show_fdinfo() and emitting a warningwhen such invocations are missed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53151 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: Address an integer overflowDan Carpenter reports:> Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data> structure") from Jun 22, 2020 (linux-next), leads to the following> Smatch static checker warning:>> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk()> warn: potential user controlled sizeof overflow 'segcount * 4 * 4'>> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c> 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt)> 489 {> 490 u32 segcount;> 491 __be32 *p;> 492> 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount))> ^^^^^^^^>> 494 return false;> 495> 496 /* A bogus segcount causes this buffer overflow check to fail. */> 497 p = xdr_inline_decode(&rctxt->rc_stream,> --> 498 segcount * rpcrdma_segment_maxsz * sizeof(*p));>>> segcount is an untrusted u32. On 32bit systems anything >= SIZE_MAX / 16 will> have an integer overflow and some those values will be accepted by> xdr_inline_decode().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53155 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix uninitialized value in ocfs2_file_read_iter()Syzbot has reported the following KMSAN splat:BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30Uninit was created at: __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250 ___slab_alloc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330 __io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30 __se_sys_io_uring_enter+0x406/0x41c0 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7fSince an instance of 'struct kiocb' may be passed from the block layerwith 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()'and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53158 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()This loop is supposed to break if the frequency returned fromclk_round_rate() is the same as on the previous iteration. However,that check doesn't make sense on the first iteration through the loop.It leads to reading before the start of these->clk_perf_tbl[] array.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53161 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/bluefield: Fix potential integer overflowThe 64-bit argument for the "get DIMM info" SMC call consists of mem_ctrl_idxleft-shifted 16 bits and OR-ed with DIMM index. With mem_ctrl_idx defined as32-bits wide the left-shift operation truncates the upper 16 bits ofinformation during the calculation of the SMC argument.The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent anypotential integer overflow, i.e. loss of data from upper 16 bits.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53213 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: lan78xx: Fix double free issue with interrupt buffer allocationIn lan78xx_probe(), the buffer `buf` was being freed twice: onceimplicitly through `usb_free_urb(dev->urb_intr)` with the`URB_FREE_BUFFER` flag and again explicitly by `kfree(buf)`. This causeda double free issue.To resolve this, reordered `kmalloc()` and `usb_alloc_urb()` calls tosimplify the initialization sequence and removed the redundant`kfree(buf)`. Now, `buf` is allocated after `usb_alloc_urb()`, ensuringit is correctly managed by `usb_fill_int_urb()` and freed by`usb_free_urb()` as intended.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56754 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: caam - Fix the pointer passed to caam_qi_shutdown()The type of the last parameter given to devm_add_action_or_reset() is"struct caam_drv_private *", but in caam_qi_shutdown(), it is casted to"struct device *".Pass the correct parameter to devm_add_action_or_reset() so that theresources are released as expected.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56769 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_regSyzbot reports [1] an uninitialized value issue found by KMSAN indib3000_read_reg().Local u8 rb[2] is used in i2c_transfer() as a read buffer; in casethat call fails, the buffer may end up with some undefined values.Since no elaborate error handling is expected in dib3000_write_reg(),simply zero out rb buffer to mitigate the problem.[1] Syzkaller reportdvb-usb: bulk message failed: -22 (6/0)=====================================================BUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31 dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline] dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310 dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110...Local variable rb created at: dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54 dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57899 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix mbss changed flags corruption on 32 bit systemsOn 32-bit systems, the size of an unsigned long is 4 bytes,while a u64 is 8 bytes. Therefore, when usingor_each_set_bit(bit, &bits, sizeof(changed) * BITS_PER_BYTE),the code is incorrectly searching for a bit in a 32-bitvariable that is expected to be 64 bits in size,leading to incorrect bit finding.Solution: Ensure that the size of the bits variable is correctlyadjusted for each architecture. Call Trace: ? show_regs+0x54/0x58 ? __warn+0x6b/0xd4 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? report_bug+0x113/0x150 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x44 ? exc_invalid_op+0x18/0x50 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? ieee80211_mesh_work+0xff/0x260 [mac80211] ? cfg80211_wiphy_work+0x72/0x98 [cfg80211] ? process_one_work+0xf1/0x1fc ? worker_thread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? mod_delayed_work_on+0x4c/0x4c ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork+0x24/0x38 ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork_asm+0xf/0x14 ? entry_INT80_32+0xf0/0xf0[restore no-op path for no changes]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58096 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor modeath11k_hal_srng_* should be used with srng->lock to protect srng data.For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),they use ath11k_hal_srng_* for many times but never call srng->lock.So when running (full) monitor mode, warning will occur:RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319So add srng->lock for them to avoid such warnings.Inorder to fetch the srng->lock, should change srng's definition from'void' to 'struct hal_srng'. And initialize them elsewhere to preventone line of code from being too long. This is consistent with other ringprocess functions, such as ath11k_dp_process_rx().Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-14104 Severity: Moderate CVSS3 score: 6.1

Description: A flaw was found in util-linux. This vulnerability allows a heap buffer overread when processing 256-byte usernames, specifically within the `setpwnam()` function, affecting SUID (Set User ID) login-utils utilities writing to the password database.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libblkid1 > 0-0 (version in image is 2.37.2-150400.8.44.1).

CVE-2025-21782 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: fix a oob in orangefs_debug_writeI got a syzbot report: slab-out-of-bounds Read inorangefs_debug_write... several people suggested fixes,I tested Al Viro's suggestion and made this patch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21922 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: Fix KMSAN uninit-value warning with bpfSyzbot caught an "KMSAN: uninit-value" warning [1], which is caused by theppp driver not initializing a 2-byte header when using socket filter.The following code can generate a PPP filter BPF program:'''struct bpf_program fp;pcap_t *handle;handle = pcap_open_dead(DLT_PPP_PPPD, 65535);pcap_compile(handle, &fp, "ip and outbound", 0, 0);bpf_dump(&fp, 1);'''Its output is:'''(000) ldh [2](001) jeq #0x21 jt 2 jf 5(002) ldb [0](003) jeq #0x1 jt 4 jf 5(004) ret #65535(005) ret #0'''Wen can find similar code at the following link:https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680The maintainer of this code repository is also the original maintainerof the ppp driver.As you can see the BPF program skips 2 bytes of data and then reads the'Protocol' field to determine if it's an IP packet. Then it read the firstbyte of the first 2 bytes to determine the direction.The issue is that only the first byte indicating direction is initializedin current ppp driver code while the second byte is not initialized.For normal BPF programs generated by libpcap, uninitialized data won't beused, so it's not a problem. However, for carefully crafted BPF programs,such as those generated by syzkaller [2], which start reading from offset0, the uninitialized data will be used and caught by KMSAN.[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791[2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21962 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing closetimeo mount optionUser-provided mount parameter closetimeo of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22022 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Apply the link chain quirk on NEC isoc endpointsTwo clearly different specimens of NEC uPD720200 (one with start/stopbug, one without) were seen to cause IOMMU faults after some MissedService Errors. Faulting address is immediately after a transfer ringsegment and patched dynamic debug messages revealed that the MSE wasreceived when waiting for a TD near the end of that segment:[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000][ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]It gets even funnier if the next page is a ring segment accessible tothe HC. Below, it reports MSE in segment at ff1e8000, plows through azero-filled page at ff1e9000 and starts reporting events for TRBs inpage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820At some point completion events change from Isoch Buffer Overrun toShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2It's possible that data from the isochronous device were written torandom buffers of pending TDs on other endpoints (either IN or OUT),other devices or even other HCs in the same IOMMU domain.Lastly, an error from a different USB device on another HC. Was itcaused by the above? I don't know, but it may have been. The diskwas working without any other issues and generated PCIe traffic tostarve the NEC of upstream BW and trigger those MSEs. The two HCsshared one x1 slot by means of a commercial "PCIe splitter" board.[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0Fortunately, it appears that this ridiculous bug is avoided by settingthe chain bit of Link TRBs on isochronous rings. Other ancient HCs areknown which also expect the bit to be set and they ignore Link TRBs ifit's not. Reportedly, 0.95 spec guaranteed that the bit is set.The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reportstens of MSEs per second and runs into the bug within seconds. ChainingLink TRBs allows the same workload to run for many minutes, many times.No ne---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22035 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix use-after-free in print_graph_function_flags during tracer switchingKairui reported a UAF issue in print_graph_function_flags() duringftrace stress testing [1]. This issue can be reproduced if puting a'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(),and executing the following script: $ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracerThe root cause lies in the two calls to print_graph_function_flagswithin print_trace_line during each s_show(): * One through 'iter->trace->print_line()'; * Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns.Tracer switching only updates the former, while the latter continuesto use the print_line function of the old tracer, which in the scriptabove is print_graph_function_flags.Moreover, when switching from the 'function_graph' tracer to the'timerlat' tracer, s_start only calls graph_trace_close of the'function_graph' tracer to free 'iter->private', but does not setit to NULL. This provides an opportunity for 'event->funcs->trace()'to use an invalid 'iter->private'.To fix this issue, set 'iter->private' to NULL immediately afterfreeing it in graph_trace_close(), ensuring that an invalid pointeris not passed to other tracers. Additionally, clean up the unnecessary'iter->private = NULL' during each 'cat trace' when using wakeup andirqsoff tracers. [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22089 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Don't expose hw_counters outside of init net namespaceCommit 467f432a521a ("RDMA/core: Split port and device counter sysfsattributes") accidentally almost exposed hw counters to non-init netnamespaces. It didn't expose them fully, as an attempt to read any ofthose counters leads to a crash like this one:[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028[42021.814463] #PF: supervisor read access in kernel mode[42021.819549] #PF: error_code(0x0000) - not-present page[42021.824636] PGD 0 P4D 0[42021.827145] Oops: 0000 [#1] SMP PTI[42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX[42021.841697] Hardware name: XXX[42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core][42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48[42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287[42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000[42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0[42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000[42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530[42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000[42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000[42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0[42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[42021.949324] Call Trace:[42021.951756] [42021.953842] [] ? show_regs+0x64/0x70[42021.959030] [] ? __die+0x78/0xc0[42021.963874] [] ? page_fault_oops+0x2b5/0x3b0[42021.969749] [] ? exc_page_fault+0x1a2/0x3c0[42021.975549] [] ? asm_exc_page_fault+0x26/0x30[42021.981517] [] ? __pfx_show_hw_stats+0x10/0x10 [ib_core][42021.988482] [] ? hw_stat_device_show+0x1e/0x40 [ib_core][42021.995438] [] dev_attr_show+0x1e/0x50[42022.000803] [] sysfs_kf_seq_show+0x81/0xe0[42022.006508] [] seq_read_iter+0xf4/0x410[42022.011954] [] vfs_read+0x16e/0x2f0[42022.017058] [] ksys_read+0x6e/0xe0[42022.022073] [] do_syscall_64+0x6a/0xa0[42022.027441] [] entry_SYSCALL_64_after_hwframe+0x78/0xe2The problem can be reproduced using the following steps: ip netns add foo ip netns exec foo bash cat /sys/class/infiniband/mlx4_0/hw_counters/*The panic occurs because of casting the device pointer into anib_device pointer using container_of() in hw_stat_device_show() iswrong and leads to a memory corruption.However the real problem is that hw counters should never been exposedoutside of the non-init net namespace.Fix this by saving the index of the corresponding attribute group(it might be 1 or 2 depending on the presence of driver-specificattributes) and zeroing the pointer to hw_counters group for compatdevices during the initialization.With this fix applied hw_counters are not available in a non-initnet namespace: find /sys/class/infiniband/mlx4_0/ -name hw_counters /sys/class/infiniband/mlx4_0/ports/1/hw_counters /sys/class/infiniband/mlx4_0/ports/2/hw_counters /sys/class/infiniband/mlx4_0/hw_counters ip netns add foo ip netns exec foo bash find /sys/class/infiniband/mlx4_0/ -name hw_counters

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22104 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Use kernel helpers for hex dumpsPreviously, when the driver was printing hex dumps, the buffer was castto an 8 byte long and printed using string formatters. If the buffersize was not a multiple of 8 then a read buffer overflow was possible.Therefore, create a new ibmvnic function that loops over a buffer andcalls hex_dump_to_buffer instead.This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvnic_login+0x2f0/0xffc [ibmvnic] ibmvnic_open+0x148/0x308 [ibmvnic] __dev_open+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37749 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef>> p *(struct pppoe_hdr *) (skb->head + skb->network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[pabeni@redhat.com: fixed subj typo]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37782 Severity: Moderate CVSS3 score: 6.1

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

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38031 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:padata: do not leak refcount in reorder_workA recent patch that addressed a UAF introduced a reference count leak:the parallel_data refcount is incremented unconditionally, regardlessof the return value of queue_work(). If the work item is already queued,the incremented refcount is never decremented.Fix this by checking the return value of queue_work() and decrementingthe refcount when necessary.Resolves:Unreferenced object 0xffff9d9f421e3d80 (size 192): comm "cryptomgr_probe", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): __kmalloc_cache_noprof+0x284/0x320 padata_alloc_pd+0x20/0x1e0 padata_alloc_shell+0x3b/0xa0 0xffffffffc040a54d cryptomgr_probe+0x43/0xc0 kthread+0xf6/0x1f0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38192 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: clear the dst when changing skb protocolA not-so-careful NAT46 BPF program can crash the kernelif it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10)The output interface has a 4->6 program attached at ingress.We try to loop the multicast skb back to the sending socket.Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdrand changes skb->protocol to v6. We enter ip6_rcv_core whichtries to use skb_dst(). But the dst is still an IPv4 one leftafter IPv4 mcast output.Clear the dst in all BPF helpers which change the protocol.Try to preserve metadata dsts, those may carry non-routingmetadata.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38310 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:seg6: Fix validation of nexthop addressesThe kernel currently validates that the length of the provided nexthopaddress does not exceed the specified length. This can lead to thekernel reading uninitialized memory if user space provided a shorterlength than the specified one.Fix by validating that the provided length exactly matches the specifiedone.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38334 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:x86/sgx: Prevent attempts to reclaim poisoned pagesTL;DR: SGX page reclaim touches the page to copy its contents tosecondary storage. SGX instructions do not gracefully handle machinechecks. Despite this, the existing SGX code will try to reclaim pagesthat it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.The longer story:Pages used by an enclave only get epc_page->poison set inarch_memory_failure() but they currently stay on sgx_active_page_list untilsgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.epc_page->poison is not checked in the reclaimer logic meaning that, if otherconditions are met, an attempt will be made to reclaim an EPC page that waspoisoned. This is bad because 1. we don't want that page to end up addedto another enclave and 2. it is likely to cause one core to shut downand the kernel to panic.Specifically, reclaiming uses microcode operations including "EWB" whichaccesses the EPC page contents to encrypt and write them out to non-SGXmemory. Those operations cannot handle MCEs in their accesses other thanby putting the executing core into a special shutdown state (affectingboth threads with HT.) The kernel will subsequently panic on theremaining cores seeing the core didn't enter MCE handler(s) in time.Call sgx_unmark_page_reclaimable() to remove the affected EPC page fromsgx_active_page_list on memory error to stop it being considered forreclaiming.Testing epc_page->poison in sgx_reclaim_pages() would also work but I assumeit's better to add code in the less likely paths.The affected EPC page is not added to &node->sgx_poison_page_list untillater in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd.Membership on other lists doesn't change to avoid changing any of thelists' semantics except for sgx_active_page_list. There's a "TBD" commentin arch_memory_failure() about pre-emptive actions, the goal here is notto address everything that it may imply.This also doesn't completely close the time window when a memory errornotification will be fatal (for a not previously poisoned EPC page) --the MCE can happen after sgx_reclaim_pages() has selected its candidatesor even *inside* a microcode operation (actually easy to trigger due tothe amount of time spent in them.)The spinlock in sgx_unmark_page_reclaimable() is safe becausememory_failure() runs in process context and no spinlocks are held,explicitly noted in a mm/memory-failure.c comment.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38502 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix oob access in cgroup local storageLonial reported that an out-of-bounds access in cgroup local storagecan be crafted via tail calls. Given two programs each utilizing acgroup local storage with a different value size, and one programdoing a tail call into the other. The verifier will validate each ofthe indivial programs just fine. However, in the runtime contextthe bpf_cg_run_ctx holds an bpf_prog_array_item which contains theBPF program as well as any cgroup local storage flavor the programuses. Helpers such as bpf_get_local_storage() pick this up from theruntime context: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf);For the second program which was called from the originally attachedone, this means bpf_get_local_storage() will pick up the formerprogram's map, not its own. With mismatching sizes, this can resultin an unintended out-of-bounds access.To fix this issue, we need to extend bpf_map_owner with an array ofstorage_cookie[] to match on i) the exact maps from the originalprogram if the second program was using bpf_get_local_storage(), orii) allow the tail call combination if the second program was notusing any of the cgroup local storage maps.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38529 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: aio_iiro_16: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: 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. 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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38530 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: pcl812: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & board->irq_bits) {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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-13595 Severity: Moderate CVSS3 score: 6.1

Description: A flaw was found in the libblkid library of util-linux. During nested partition probing, the BSD, Minix, Solaris x86, and UnixWare partition probers cache a raw pointer to a parent partition entry in a dynamically allocated array. When subsequent partition additions cause the array to be reallocated, this pointer becomes stale, leading to a heap use-after-free read. An attacker who can present a crafted block device image (for example, via USB insertion or a loop-mounted disk image) can trigger this flaw without user interaction, as libblkid is invoked automatically by udev/udisks as root on block-device hot-plug events. This could lead to limited information disclosure or denial of service.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libblkid1 > 0-0 (version in image is 2.37.2-150400.8.44.1).

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-22978 Severity: Moderate CVSS3 score: 6.1

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23112 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovecnvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDUlength or offset exceeds sg_cnt and then use bogus sg->length/offsetvalues, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remainingentries, and sg->length/offset before building the bvec.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23434 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: serialize lock/unlock against other NAND operationsnand_lock() and nand_unlock() call into chip->ops.lock_area/unlock_areawithout holding the NAND device lock. On controllers that implementSET_FEATURES via multiple low-level PIO commands, these can race withconcurrent UBI/UBIFS background erase/write operations that hold thedevice lock, resulting in cmd_pending conflicts on the NAND controller.Add nand_get_device()/nand_release_device() around the lock/unlockoperations to serialize them against all other NAND controller access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23447 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds checkThe same bounds-check bug fixed for NDP16 in the previous patch alsoexists in cdc_ncm_rx_verify_ndp32(). The DPE array size is validatedagainst the total skb length without accounting for ndpoffset, allowingout-of-bounds reads when the NDP32 is placed near the end of the NTB.Add ndpoffset to the nframes bounds check and use struct_size_t() toexpress the NDP-plus-DPE-array size more clearly.Compile-tested only.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23448 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: cdc_ncm: add ndpoffset to NDP16 nframes bounds checkcdc_ncm_rx_verify_ndp16() validates that the NDP header and its DPEentries fit within the skb. The first check correctly accounts forndpoffset: if ((ndpoffset + sizeof(struct usb_cdc_ncm_ndp16)) > skb_in->len)but the second check omits it: if ((sizeof(struct usb_cdc_ncm_ndp16) + ret * (sizeof(struct usb_cdc_ncm_dpe16))) > skb_in->len)This validates the DPE array size against the total skb length as ifthe NDP were at offset 0, rather than at ndpoffset. When the NDP isplaced near the end of the NTB (large wNdpIndex), the DPE entries canextend past the skb data buffer even though the check passes.cdc_ncm_rx_fixup() then reads out-of-bounds memory when iteratingthe DPE array.Add ndpoffset to the nframes bounds check and use struct_size_t() toexpress the NDP-plus-DPE-array size more clearly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23465 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: log new dentries when logging parent dir of a conflicting inodeIf we log the parent directory of a conflicting inode, we are not loggingthe new dentries of the directory, so when we finish we have the parentdirectory's inode marked as logged but we did not log its new dentries.As a consequence if the parent directory is explicitly fsynced later andit does not have any new changes since we logged it, the fsync is a no-opand after a power failure the new dentries are missing.Example scenario: $ mkdir foo $ sync $rmdir foo $ mkdir dir1 $ mkdir dir2 # A file with the same name and parent as the directory we just deleted # and was persisted in a past transaction. So the deleted directory's # inode is a conflicting inode of this new file's inode. $ touch foo $ ln foo dir2/link # The fsync on dir2 will log the parent directory (".") because the # conflicting inode (deleted directory) does not exists anymore, but it # it does not log its new dentries (dir1). $ xfs_io -c "fsync" dir2 # This fsync on the parent directory is no-op, since the previous fsync # logged it (but without logging its new dentries). $ xfs_io -c "fsync" . # After log replay dir1 is missing.Fix this by ensuring we log new dir dentries whenever we log the parentdirectory of a no longer existing conflicting inode.A test case for fstests will follow soon.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31392 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix krb5 mount with username optionCustomer reported that some of their krb5 mounts were failing againsta single server as the client was trying to mount the shares withwrong credentials. It turned out the client was reusing SMB sessionfrom first mount to try mounting the other shares, even though adifferent username= option had been specified to the other mounts.By using username mount option along with sec=krb5 to search forprincipals from keytab is supported by cifs.upcall(8) sincecifs-utils-4.8. So fix this by matching username mount option inmatch_session() even with Kerberos.For example, the second mount below should fail with -ENOKEY as thereis no 'foobar' principal in keytab (/etc/krb5.keytab). The clientends up reusing SMB session from first mount to perform the secondone, which is wrong.```$ ktutilktutil: add_entry -password -p testuser -k 1 -e aes256-ctsPassword for testuser@ZELDA.TEST:ktutil: write_kt /etc/krb5.keytabktutil: quit$ klist -keKeytab name: FILE:/etc/krb5.keytabKVNO Principal ---- ---------------------------------------------------------------- 1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96)$ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser$ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar$ mount -t cifs | grep -Po 'username=\K\w+'testusertestuser```

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31396 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: fix use-after-free access to PTP clockPTP clock is registered on every opening of the interface and destroyed onevery closing. However it may be accessed via get_ts_info ethtool callwhich is possible while the interface is just present in the kernel.BUG: KASAN: use-after-free in ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426Read of size 4 at addr ffff8880194345cc by task syz.0.6/948CPU: 1 PID: 948 Comm: syz.0.6 Not tainted 6.1.164+ #109Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x17f/0x496 mm/kasan/report.c:420 kasan_report+0xd9/0x180 mm/kasan/report.c:524 ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 gem_get_ts_info+0x138/0x1e0 drivers/net/ethernet/cadence/macb_main.c:3349 macb_get_ts_info+0x68/0xb0 drivers/net/ethernet/cadence/macb_main.c:3371 __ethtool_get_ts_info+0x17c/0x260 net/ethtool/common.c:558 ethtool_get_ts_info net/ethtool/ioctl.c:2367 [inline] __dev_ethtool net/ethtool/ioctl.c:3017 [inline] dev_ethtool+0x2b05/0x6290 net/ethtool/ioctl.c:3095 dev_ioctl+0x637/0x1070 net/core/dev_ioctl.c:510 sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215 sock_ioctl+0x577/0x6d0 net/socket.c:1320 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 457: kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:699 [inline] ptp_clock_register+0x144/0x10e0 drivers/ptp/ptp_clock.c:235 gem_ptp_init+0x46f/0x930 drivers/net/ethernet/cadence/macb_ptp.c:375 macb_open+0x901/0xd10 drivers/net/ethernet/cadence/macb_main.c:2920 __dev_open+0x2ce/0x500 net/core/dev.c:1501 __dev_change_flags+0x56a/0x740 net/core/dev.c:8651 dev_change_flags+0x92/0x170 net/core/dev.c:8722 do_setlink+0xaf8/0x3a80 net/core/rtnetlink.c:2833 __rtnl_newlink+0xbf4/0x1940 net/core/rtnetlink.c:3608 rtnl_newlink+0x63/0xa0 net/core/rtnetlink.c:3655 rtnetlink_rcv_msg+0x3c6/0xed0 net/core/rtnetlink.c:6150 netlink_rcv_skb+0x15d/0x430 net/netlink/af_netlink.c:2511 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x6d7/0xa30 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x97e/0xeb0 net/netlink/af_netlink.c:1872 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x14b/0x180 net/socket.c:730 __sys_sendto+0x320/0x3b0 net/socket.c:2152 __do_sys_sendto net/socket.c:2164 [inline] __se_sys_sendto net/socket.c:2160 [inline] __x64_sys_sendto+0xdc/0x1b0 net/socket.c:2160 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8Freed by task 938: kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1729 [inline] slab_free_freelist_hook mm/slub.c:1755 [inline] slab_free mm/slub.c:3687 [inline] __kmem_cache_free+0xbc/0x320 mm/slub.c:3700 device_release+0xa0/0x240 drivers/base/core.c:2507 kobject_cleanup lib/kobject.c:681 [inline] kobject_release lib/kobject.c:712 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1cd/0x350 lib/kobject.c:729 put_device+0x1b/0x30 drivers/base/core.c:3805 ptp_clock_unregister+0x171/0x270 drivers/ptp/ptp_clock.c:391 gem_ptp_remove+0x4e/0x1f0 drivers/net/ethernet/cadence/macb_ptp.c:404 macb_close+0x1c8/0x270 drivers/net/ethernet/cadence/macb_main.c:2966 __dev_close_many+0x1b9/0x310 net/core/dev.c:1585 __dev_close net/core/dev.c:1597 [inline] __dev_change_flags+0x2bb/0x740 net/core/dev.c:8649 dev_change_fl---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31503 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:udp: Fix wildcard bind conflict check when using hash2When binding a udp_sock to a local address and port, UDP usestwo hashes (udptable->hash and udptable->hash2) for collisiondetection. The current code switches to "hash2" whenhslot->count > 10."hash2" is keyed by local address and local port."hash" is keyed by local port only.The issue can be shown in the following bind sequence (pseudo code):bind(fd1, "[fd00::1]:8888")bind(fd2, "[fd00::2]:8888")bind(fd3, "[fd00::3]:8888")bind(fd4, "[fd00::4]:8888")bind(fd5, "[fd00::5]:8888")bind(fd6, "[fd00::6]:8888")bind(fd7, "[fd00::7]:8888")bind(fd8, "[fd00::8]:8888")bind(fd9, "[fd00::9]:8888")bind(fd10, "[fd00::10]:8888")/* Correctly return -EADDRINUSE because "hash" is used * instead of "hash2". udp_lib_lport_inuse() detects the * conflict. */bind(fail_fd, "[::]:8888")/* After one more socket is bound to "[fd00::11]:8888", * hslot->count exceeds 10 and "hash2" is used instead. */bind(fd11, "[fd00::11]:8888")bind(fail_fd, "[::]:8888") /* succeeds unexpectedly */The same issue applies to the IPv4 wildcard address "0.0.0.0"and the IPv4-mapped wildcard address "::ffff:0.0.0.0". Forexample, if there are existing sockets bound to"192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or"[::ffff:0.0.0.0]:8888" can also miss the conflict whenhslot->count > 10.TCP inet_csk_get_port() already has the correct check ininet_use_bhash2_on_bind(). Rename it toinet_use_hash2_on_bind() and move it to inet_hashtables.hso udp.c can reuse it in this fix.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31585 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: fix nfeeds state corruption on start_streaming failuresyzbot reported a memory leak in vidtv_psi_service_desc_init [1].When vidtv_start_streaming() fails inside vidtv_start_feed(), thenfeeds counter is left incremented even though no feed was actuallystarted. This corrupts the driver state: subsequent start_feed callssee nfeeds > 1 and skip starting the mux, while stop_feed callseventually try to stop a non-existent stream.This state corruption can also lead to memory leaks, since the muxand channel resources may be partially allocated during a failedstart_streaming but never cleaned up, as the stop path findsdvb->streaming == false and returns early.Fix by decrementing nfeeds back when start_streaming fails, keepingthe counter in sync with the actual number of active feeds.[1]BUG: memory leakunreferenced object 0xffff888145b50820 (size 32): comm "syz.0.17", pid 6068, jiffies 4294944486 backtrace (crc 90a0c7d4): vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31606 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_hid: don't call cdev_init while cdev in useWhen calling unbind, then bind again, cdev_init reinitialized the cdev,even though there may still be references to it. That's the case whenthe /dev/hidg* device is still opened. This obviously unsafe behaviorlike oopes.This fixes this by using cdev_alloc to put the cdev on the heap. Thatway, we can simply allocate a new one in hidg_bind.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31617 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb()The block_len read from the host-supplied NTB header is checked againstntb_max but has no lower bound. When block_len is smaller thanopts->ndp_size, the bounds check of: ndp_index > (block_len - opts->ndp_size)will underflow producing a huge unsigned value that ndp_index can neverexceed, defeating the check entirely.The same underflow occurs in the datagram index checks against block_len- opts->dpe_size. With those checks neutered, a malicious USB host canchoose ndp_index and datagram offsets that point past the actualtransfer, and the skb_put_data() copies adjacent kernel memory into thenetwork skb.Fix this by rejecting block lengths that cannot hold at least the NTBheader plus one NDP. This will make block_len - opts->ndp_size andblock_len - opts->dpe_size both well-defined.Commit 8d2b1a1ec9f5 ("CDC-NCM: avoid overflow in sanity checking") fixeda related class of issues on the host side of NCM.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31619 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: fireworks: bound device-supplied status before string array lookupThe status field in an EFW response is a 32-bit value supplied by thefirewire device. efr_status_names[] has 17 entries so a status valueoutside that range goes off into the weeds when looking at the %s value.Even worse, the status could return EFR_STATUS_INCOMPLETE which is0x80000000, and is obviously not in that array of potential strings.Fix this up by properly bounding the index against the array size andprinting "unknown" if it's not recognized.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31722 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_rndis: Fix net_device lifecycle with device_moveThe net_device is allocated during function instance creation andregistered during the bind phase with the gadget device as its sysfsparent. When the function unbinds, the parent device is destroyed, butthe net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directoryUse device_move() to reparent the net_device between the gadget devicetree and /sys/devices/virtual across bind and unbind cycles. During thefinal unbind, calling device_move(NULL) moves the net_device to thevirtual device tree before the gadget device is destroyed. On rebinding,device_move() reparents the device back under the new gadget, ensuringproper sysfs topology and power management ordering.To maintain compatibility with legacy composite drivers (e.g., multi.c),the borrowed_net flag is used to indicate whether the network device isshared and pre-registered during the legacy driver's bind phase.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31723 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_subset: Fix net_device lifecycle with device_moveThe net_device is allocated during function instance creation andregistered during the bind phase with the gadget device as its sysfsparent. When the function unbinds, the parent device is destroyed, butthe net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directoryUse device_move() to reparent the net_device between the gadget devicetree and /sys/devices/virtual across bind and unbind cycles. During thefinal unbind, calling device_move(NULL) moves the net_device to thevirtual device tree before the gadget device is destroyed. On rebinding,device_move() reparents the device back under the new gadget, ensuringproper sysfs topology and power management ordering.To maintain compatibility with legacy composite drivers (e.g., multi.c),the bound flag is used to indicate whether the network device is sharedand pre-registered during the legacy driver's bind phase.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31724 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_eem: Fix net_device lifecycle with device_moveThe net_device is allocated during function instance creation andregistered during the bind phase with the gadget device as its sysfsparent. When the function unbinds, the parent device is destroyed, butthe net_device survives, resulting in dangling sysfs symlinks:console:/ # ls -l /sys/class/net/usb0lrwxrwxrwx ... /sys/class/net/usb0 ->/sys/devices/platform/.../gadget.0/net/usb0console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0ls: .../gadget.0/net/usb0: No such file or directoryUse device_move() to reparent the net_device between the gadget devicetree and /sys/devices/virtual across bind and unbind cycles. During thefinal unbind, calling device_move(NULL) moves the net_device to thevirtual device tree before the gadget device is destroyed. On rebinding,device_move() reparents the device back under the new gadget, ensuringproper sysfs topology and power management ordering.To maintain compatibility with legacy composite drivers (e.g., multi.c),the bound flag is used to indicate whether the network device is sharedand pre-registered during the legacy driver's bind phase.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31778 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: caiaq: fix stack out-of-bounds read in init_cardThe loop creates a whitespace-stripped copy of the card shortnamewhere `len < sizeof(card->id)` is used for the bounds check. Sincesizeof(card->id) is 16 and the local id buffer is also 16 bytes,writing 16 non-space characters fills the entire buffer,overwriting the terminating nullbyte.When this non-null-terminated string is later passed tosnd_card_set_id() -> copy_valid_id_string(), the function scansforward with `while (*nid && ...)` and reads past the end of thestack buffer, reading the contents of the stack.A USB device with a product name containing many non-ASCII, non-spacecharacters (e.g. multibyte UTF-8) will reliably trigger this as follows: BUG: KASAN: stack-out-of-bounds in copy_valid_id_string sound/core/init.c:696 [inline] BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c sound/core/init.c:718The off-by-one has been present since commit bafeee5b1f8d ("ALSA:snd_usb_caiaq: give better shortname") from June 2009 (v2.6.31-rc1),which first introduced this whitespace-stripping loop. The originalcode never accounted for the null terminator when bounding the copy.Fix this by changing the loop bound to `sizeof(card->id) - 1`,ensuring at least one byte remains as the null terminator.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-39979 Severity: Moderate CVSS3 score: 6.1

Description: jq is a command-line JSON processor. In commits before 2f09060afab23fe9390cce7cb860b10416e1bf5f, the jv_parse_sized() API in libjq accepts a counted buffer with an explicit length parameter, but its error-handling path formats the input buffer using %s in jv_string_fmt(), which reads until a NUL terminator is found rather than respecting the caller-supplied length. This means that when malformed JSON is passed in a non-NUL-terminated buffer, the error construction logic performs an out-of-bounds read past the end of the buffer. The vulnerability is reachable by any libjq consumer calling jv_parse_sized() with untrusted input, and depending on memory layout, can result in memory disclosure or process termination. The issue has been patched in commit 2f09060afab23fe9390cce7cb860b10416e1bf5f.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
jq > 0-0 (version in image is 1.6-150000.3.12.1).

CVE-2026-41992 Severity: Moderate CVSS3 score: 6.1

Description: GNU gzip contains a global buffer overflow vulnerability in the LZH decompression logic caused by improper reuse of shared global state between different decompression formats within a single execution. GNU gzip maintains a global array that is shared across the LZ77, LZW, and LZH decompression routines and is not reinitialized between files processed in the same invocation.By decompressing a specially crafted LZW file followed by a specially crafted LZH file in a single gzip -d command, an attacker can poison the shared global state and subsequently trigger an out-of-bounds read in the LZH decoder. The LZH decompression logic follows stale values left in the shared array, causing reads past the end of the allocated global buffer.This issue has been fixed in the commit 63dbf6b3b9e6e781df1a6a64e609b10e23969681

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
gzip > 0-0 (version in image is 1.10-150200.10.1).

CVE-2026-43052 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: check tdls flag in ieee80211_tdls_operWhen NL80211_TDLS_ENABLE_LINK is called, the code only checks if thestation exists but not whether it is actually a TDLS station. Thisallows the operation to proceed for non-TDLS stations, causingunintended side effects like modifying channel context and HTprotection before failing.Add a check for sta->sta.tdls early in the ENABLE_LINK case, beforeany side effects occur, to ensure the operation is only allowed foractual TDLS peers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43071 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:dcache: Limit the minimal number of bucket to twoThere is an OOB read problem on dentry_hashtable when user sets'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260There will be only one bucket in dentry_hashtable when dhash_entries isset as one, and d_hash_shift is calculated as 32 by dcache_init(). Then,following process will access more than one buckets(which memory regionis not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB!Fix it by limiting the minimal number of dentry_hashtable bucket to two,so that 'd_hash_shift' won't exceeds the bit width of type u32.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45856 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_sendib_uverbs_post_send() uses cmd.wqe_size from userspace without anyvalidation before passing it to kmalloc() and using the allocatedbuffer as struct ib_uverbs_send_wr.If a user provides a small wqe_size value (e.g., 1), kmalloc() willsucceed, but subsequent accesses to user_wr->opcode, user_wr->num_sge,and other fields will read beyond the allocated buffer, resulting inan out-of-bounds read from kernel heap memory. This could potentiallyleak sensitive kernel information to userspace.Additionally, providing an excessively large wqe_size can trigger aWARNING in the memory allocation path, as reported by syzkaller.This is inconsistent with ib_uverbs_unmarshall_recv() which properlyvalidates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) beforeproceeding.Add the same validation for ib_uverbs_post_send() to ensure wqe_sizeis at least sizeof(struct ib_uverbs_send_wr).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-46070 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid5: validate payload size before accessing journal metadatar5c_recovery_analyze_meta_block() andr5l_recovery_verify_data_checksum_for_mb() iterate over payloads in ajournal metadata block using on-disk payload size fields withoutvalidating them against the remaining space in the metadata block.A corrupted journal contains payload sizes extending beyond the PAGE_SIZEboundary can cause out-of-bounds reads when accessing payload fields orcomputing offsets.Add bounds validation for each payload type to ensure the full payloadfits within meta_size before processing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-46107 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:dm-thin: fix metadata refcount underflowThere's a bug in dm-thin in the function rebalance_children. If theinternal btree node has one entry, the code tries to copy all btreeentries from the node's child to the node itself and then decrement thechild's reference count.If the child node is shared (it has reference count > 1), we won't freeit, so there would be two pointers to each of the grandchildren nodes.But the reference counts of the grandchildren is not increased, thus thereference count doesn't match the number of pointers that point to thegrandchildren. This results in "device mapper: space map common: unableto decrement block" errors.Fix this bug by incrementing reference counts on the grandchildren if thebtree node is shared.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-46122 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: b43: enforce bounds check on firmware key index in b43_rx()The firmware-controlled key index in b43_rx() can exceed the dev->key[]array size (58 entries). The existing B43_WARN_ON is non-enforcing inproduction builds, allowing an out-of-bounds read.Make the B43_WARN_ON check enforcing by dropping the frame when thefirmware returns an invalid key index.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-52914 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: fix fragment reassembly length accountingbatman-adv keeps a running payload length for queued fragments and uses itto validate a fragment chain before reassembly.That accounting currently allows the accumulated fragment length to betruncated during updates. As a result, malformed fragment chains canbypass the intended validation and drive reassembly with inconsistentlength state, leading to a local denial of service.Fix the accounting by storing the accumulated length in a length-typedfield and rejecting update overflows before the existing validation logicruns.The fix was verified against the original reproducer and against validfragment reassembly paths.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53075 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: require CAP_NET_ADMIN in target netns for unattached ioctls/dev/ppp open is currently authorized against file->f_cred->user_ns,while unattached administrative ioctls operate on current->nsproxy->net_ns.As a result, a local unprivileged user can create a new user namespacewith CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace,and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN againstan inherited network namespace.Require CAP_NET_ADMIN in the user namespace that owns the target networknamespace before handling unattached PPP administrative ioctls.This preserves normal pppd operation in the network namespace it isactually privileged in, while rejecting the userns-only inherited-netnscase.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53091 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: pull headers in qdisc_pkt_len_segs_init()Most ndo_start_xmit() methods expects headers of gso packetsto be already in skb->head.net/core/tso.c users are particularly at risk, because tso_build_hdr()does a memcpy(hdr, skb->data, hdr_len);qdisc_pkt_len_segs_init() already does a dissection of gso packets.Use pskb_may_pull() instead of skb_header_pointer() to makesure drivers do not have to reimplement this.Some malicious packets could be fed, detect them so that we candrop them sooner with a new SKB_DROP_REASON_SKB_BAD_GSO drop_reason.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53148 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:thunderbolt: Clamp XDomain response data copy to allocation sizetb_xdp_properties_request() derives the per-packet copy length fromthe response header without checking that it fits in the previouslyallocated data buffer. A malicious peer can set its length fieldlarger than the declared data_length, causing memcpy to write pastthe kcalloc allocation.Clamp the per-packet copy length so that the cumulative offsetnever exceeds data_len.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53150 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:thunderbolt: Reject zero-length property entries in validatortb_property_entry_valid() accepts entries with length == 0 forDIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passesvalidation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\0';When property->length is 0 this writes to offset -1 relative tothe allocation.Reject zero-length entries early in the validator since they have novalid representation in the XDomain property protocol.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53306 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:tty: hvc_iucv: fix off-by-one in number of supported devicesMAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8.This is the number of entries in: static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES];Sometimes hvc_iucv_table[] is limited by:(a) if (num > hvc_iucv_devices) // for error detectionor(b) for (i = 0; i < hvc_iucv_devices; i++) // in 2 places(so these 2 don't agree; second one appears to be correct to me.)hvc_iucv_devices can be 0..8. This is a counter.(c) if (hvc_iucv_devices > MAX_HVC_IUCV_LINES)If hvc_iucv_devices == 8, (a) allows the code to access hvc_iucv_table[8].Oops.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-57451 Severity: Moderate CVSS3 score: 6.1

Description: Vim is an open source, command line text editor. Prior to 9.2.0670, get_text_props() in src/textprop.c reads a uint16 property count stored inline after a line's text and returns it as the number of 32-byte textprop_T entries that follow. The only check is a floor that guarantees room for a single entry; the count is never checked against the amount of data actually present. A line that declares a large count while carrying little data causes consumers to read far past the end of the line buffer. Such a line can be delivered through a crafted undo file, leading to a crash. This vulnerability is fixed in 9.2.0670.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.2.0280-150000.5.89.1).

CVE-2026-57454 Severity: Moderate CVSS3 score: 6.1

Description: Vim is an open source, command line text editor. From 9.2.0320 until 9.2.0679, a crafted undo or swap file can store a virtual-text property whose offset and length point outside the line's property data. When Vim restores or displays such a line it converts the offset into a pointer and reads the virtual text without bounds checking, causing an out-of-bounds read that can crash Vim or disclose adjacent heap memory. This vulnerability is fixed in 9.2.0679.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.2.0280-150000.5.89.1).

CVE-2023-52612 Severity: Important CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: scomp - fix req->dst buffer overflowThe req->dst buffer size should be checked before copying from thescomp_scratch->dst to avoid req->dst buffer overflow problem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50650 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix reference state management for synchronous callbacksCurrently, verifier verifies callback functions (sync and async) as ifthey will be executed once, (i.e. it explores execution state as if thefunction was being called once). The next insn to explore is set tostart of subprog and the exit from nested frame is handled usingcurframe > 0 and prepare_func_exit. In case of async callback it uses acustomized variant of push_stack simulating a kind of branch to set upcustom state and execution context for the async callback.While this approach is simple and works when callback really will beexecuted only once, it is unsafe for all of our current helpers whichare for_each style, i.e. they execute the callback multiple times.A callback releasing acquired references of the caller may do somultiple times, but currently verifier sees it as one call inside theframe, which then returns to caller. Hence, it thinks it released somereference that the cb e.g. got access through callback_ctx (registerfilled inside cb from spilled typed register on stack).Similarly, it may see that an acquire call is unpaired inside thecallback, so the caller will copy the reference state of callback andthen will have to release the register with new ref_obj_ids. But again,the callback may execute multiple times, but the verifier will onlyaccount for acquired references for a single symbolic execution of thecallback, which will cause leaks.Note that for async callback case, things are different. While currentlywe have bpf_timer_set_callback which only executes it once, even formultiple executions it would be safe, as reference state is NULL andcheck_reference_leak would force program to release state beforeBPF_EXIT. The state is also unaffected by analysis for the caller frame.Hence async callback is safe.Since we want the reference state to be accessible, e.g. for pointersloaded from stack through callback_ctx's PTR_TO_STACK, we still have tocopy caller's reference_state to callback's bpf_func_state, but weenforce that whatever references it adds to that reference_state hasbeen released before it hits BPF_EXIT. This requires introducing a newcallback_ref member in the reference state to distinguish between callervs callee references. Hence, check_reference_leak now errors out if itsees we are in callback_fn and we have not released callback_ref refs.Since there can be multiple nested callbacks, like frame 0 -> cb1 -> cb2etc. we need to also distinguish between whether this particular refbelongs to this callback frame or parent, and only error for our own, sowe store state->frameno (which is always non-zero for callbacks).In short, callbacks can read parent reference_state, but cannot mutateit, to be able to use pointers acquired by the caller. They must onlyundo their changes (by releasing their own acquired_refs beforeBPF_EXIT) on top of caller reference_state before returning (at whichpoint the caller and callback state will match anyway, so no need tocopy it back to caller).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53586 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix multiple LUN_RESET handlingThis fixes a bug where an initiator thinks a LUN_RESET has cleaned uprunning commands when it hasn't. The bug was added in commit 51ec502a3266("target: Delete tmr from list before processing").The problem occurs when: 1. We have N I/O cmds running in the target layer spread over 2 sessions. 2. The initiator sends a LUN_RESET for each session. 3. session1's LUN_RESET loops over all the running commands from both sessions and moves them to its local drain_task_list. 4. session2's LUN_RESET does not see the LUN_RESET from session1 because the commit above has it remove itself. session2 also does not see any commands since the other reset moved them off the state lists. 5. sessions2's LUN_RESET will then complete with a successful response. 6. sessions2's inititor believes the running commands on its session are now cleaned up due to the successful response and cleans up the running commands from its side. It then restarts them. 7. The commands do eventually complete on the backend and the target starts to return aborted task statuses for them. The initiator will either throw a invalid ITT error or might accidentally lookup a new task if the ITT has been reallocated already.Fix the bug by reverting the patch, and serialize the execution ofLUN_RESETs and Preempt and Aborts.Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list,because it turns out the original patch fixed a bug that was notmentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a secondLUN_RESET and wait on it. Then the second reset will runcore_tmr_drain_tmr_list and see the first reset and wait on it resulting ina deadlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36910 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Don't free decrypted memoryIn CoCo VMs it is possible for the untrusted host to causeset_memory_encrypted() or set_memory_decrypted() to fail such that anerror is returned and the resulting memory is shared. Callers need totake care to handle these errors to avoid returning decrypted (shared)memory to the page allocator, which could lead to functional or securityissues.The VMBus device UIO driver could free decrypted/shared pages ifset_memory_decrypted() fails. Check the decrypted field in the gpadlto decide whether to free the memory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41038 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headersCheck that all fields of a V2 algorithm header fit into the availablefirmware data buffer.The wmfw V2 format introduced variable-length strings in the algorithmblock header. This means the overall header length is variable, and theposition of most fields varies depending on the length of the stringfields. Each field must be checked to ensure that it does not overflowthe firmware data buffer.As this ia bugfix patch, the fixes avoid making any significant change tothe existing code. This makes it easier to review and less likely tointroduce new bugs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47742 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:firmware_loader: Block path traversalMost firmware names are hardcoded strings, or are constructed from fairlyconstrained format strings where the dynamic parts are just some hexnumbers or such.However, there are a couple codepaths in the kernel where firmware filenames contain string components that are passed through from a device orsemi-privileged userspace; the ones I could find (not counting interfacesthat require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic_%s", and there shouldn't be any *folders* starting with "netronome/nic_". The previous case was different because there, the "%s" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.)Fix it by rejecting any firmware names containing ".." path components.For what it's worth, I went looking and haven't found any USB devicedrivers that use the firmware loader dangerously.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56566 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:mm/slub: Avoid list corruption when removing a slab from the full listBoot with slub_debug=UFPZ.If allocated object failed in alloc_consistency_checks, all objects ofthe slab will be marked as used, and then the slab will be removed fromthe partial list.When an object belonging to the slab got freed later, the remove_full()function is called. Because the slab is neither on the partial list noron the full list, it eventually lead to a list corruption (actually alist poison being detected).So we need to mark and isolate the slab page with metadata corruption,do not put it back in circulation.Because the debug caches avoid all the fastpaths, reusing the frozen bitto mark slab page with metadata corruption seems to be fine.[ 4277.385669] list_del corruption, ffffea00044b3e50->next is LIST_POISON1 (dead000000000100)[ 4277.387023] ------------[ cut here ]------------[ 4277.387880] kernel BUG at lib/list_debug.c:56![ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI[ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1[ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs][ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0[ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91[ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082[ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000[ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff[ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0[ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910[ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0[ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000[ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0[ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 4277.410000] PKRU: 55555554[ 4277.410645] Call Trace:[ 4277.411234] [ 4277.411777] ? die+0x32/0x80[ 4277.412439] ? do_trap+0xd6/0x100[ 4277.413150] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.414158] ? do_error_trap+0x6a/0x90[ 4277.414948] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.415915] ? exc_invalid_op+0x4c/0x60[ 4277.416710] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.417675] ? asm_exc_invalid_op+0x16/0x20[ 4277.418482] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.419466] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.420410] free_to_partial_list+0x515/0x5e0[ 4277.421242] ? xfs_iext_remove+0x41a/0xa10 [xfs][ 4277.422298] xfs_iext_remove+0x41a/0xa10 [xfs][ 4277.423316] ? xfs_inodegc_worker+0xb4/0x1a0 [xfs][ 4277.424383] xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs][ 4277.425490] __xfs_bunmapi+0x50d/0x840 [xfs][ 4277.426445] xfs_itruncate_extents_flags+0x13a/0x490 [xfs][ 4277.427553] xfs_inactive_truncate+0xa3/0x120 [xfs][ 4277.428567] xfs_inactive+0x22d/0x290 [xfs][ 4277.429500] xfs_inodegc_worker+0xb4/0x1a0 [xfs][ 4277.430479] process_one_work+0x171/0x340[ 4277.431227] worker_thread+0x277/0x390[ 4277.431962] ? __pfx_worker_thread+0x10/0x10[ 4277.432752] kthread+0xf0/0x120[ 4277.433382] ? __pfx_kthread+0x10/0x10[ 4277.434134] ret_from_fork+0x2d/0x50[ 4277.434837] ? __pfx_kthread+0x10/0x10[ 4277.435566] ret_from_fork_asm+0x1b/0x30[ 4277.436280]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-40281 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rtosyzbot reported a possible shift-out-of-bounds [1]Blamed commit added rto_alpha_max and rto_beta_max set to 1000.It is unclear if some sctp users are setting very large rto_alphaand/or rto_beta.In order to prevent user regression, perform the test at run time.Also add READ_ONCE() annotations as sysctl values can change under us.[1]UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41shift exponent 64 is too large for 32-bit type 'unsigned int'CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:233 [inline] __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494 sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509 sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502 sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-61915 Severity: Moderate CVSS3 score: 6.0

Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to version 2.4.15, a user in the lpadmin group can use the cups web ui to change the config and insert a malicious line. Then the cupsd process which runs as root will parse the new config and cause an out-of-bound write. This issue has been patched in version 2.4.15.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
cups-config > 0-0 (version in image is 2.2.7-150000.3.86.1).

CVE-2026-31747 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: me4000: Fix potential overrun of firmware buffer`me4000_xilinx_download()` loads the firmware that was requested by`request_firmware()`. It is possible for it to overrun the sourcebuffer because it blindly trusts the file format. It reads a datastream length from the first 4 bytes into variable `file_length` andreads the data stream contents of length `file_length` from offset 16onwards.Add a test to ensure that the supplied firmware is long enough tocontain the header and the data stream. On failure, log an error andreturn `-EINVAL`.Note: The firmware loading was totally broken before commit ac584af59945("staging: comedi: me4000: fix firmware downloading"), but that is themost sensible target for this fix.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31748 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: me_daq: Fix potential overrun of firmware buffer`me2600_xilinx_download()` loads the firmware that was requested by`request_firmware()`. It is possible for it to overrun the sourcebuffer because it blindly trusts the file format. It reads a datastream length from the first 4 bytes into variable `file_length` andreads the data stream contents of length `file_length` from offset 16onwards. Although it checks that the supplied firmware is at least 16bytes long, it does not check that it is long enough to contain the datastream.Add a test to ensure that the supplied firmware is long enough tocontain the header and the data stream. On failure, log an error andreturn `-EINVAL`.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-39881 Severity: Moderate CVSS3 score: 6.0

Description: Vim is an open source, command line text editor. Prior to 9.2.0316, a command injection vulnerability in Vim's netbeans interface allows a malicious netbeans server to execute arbitrary Ex commands when Vim connects to it, via unsanitized strings in the defineAnnoType and specialKeys protocol messages. This vulnerability is fixed in 9.2.0316.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim < 9.2.0530-150000.5.94.1 (version in image is 9.2.0280-150000.5.89.1).

CVE-2026-46023 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:dm mirror: fix integer overflow in create_dirty_log()The argument count calculation in create_dirty_log() performs`*args_used = 2 + param_count` before validating against argc. When auser provides a param_count close to UINT_MAX via the device mappertable string, this unsigned addition wraps around to a small value,causing the subsequent `argc < *args_used` check to be bypassed.The overflowed param_count is then passed as argc to dm_dirty_log_create(),where it can cause out-of-bounds reads on the argv array.Fix by comparing param_count against argc - 2 before performing theaddition, following the same pattern used by parse_features() in thesame file. Since argc >= 2 is already guaranteed, the subtraction issafe.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-48795 Severity: Important CVSS3 score: 5.9

Description: The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libssh-config > 0-0 (version in image is 0.9.8-150400.3.17.1).

CVE-2022-50483 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: avoid buffer leaks on xdp_do_redirect() failureBefore enetc_clean_rx_ring_xdp() calls xdp_do_redirect(), each softwareBD in the RX ring between index orig_i and i can have one of 2 refcountvalues on its page.We are the owner of the current buffer that is being processed, so therefcount will be at least 1.If the current owner of the buffer at the diametrically opposed indexin the RX ring (i.o.w, the other half of this page) has not yet calledkfree(), this page's refcount could even be 2.enetc_page_reusable() in enetc_flip_rx_buff() tests for the pagerefcount against 1, and [ if it's 2 ] does not attempt to reuse it.But if enetc_flip_rx_buff() is put after the xdp_do_redirect() call,the page refcount can have one of 3 values. It can also be 0, if thereis no owner of the other page half, and xdp_do_redirect() for thisbuffer ran so far that it triggered a flush of the devmap/cpumap bulkqueue, and the consumers of those bulk queues also freed the buffer,all by the time xdp_do_redirect() returns the execution back to enetc.This is the reason why enetc_flip_rx_buff() is called beforexdp_do_redirect(), but there is a big flaw with that reasoning:enetc_flip_rx_buff() will set rx_swbd->page = NULL on both sides of theenetc_page_reusable() branch, and if xdp_do_redirect() returns an error,we call enetc_xdp_free(), which does not deal gracefully with that.In fact, what happens is quite special. The page refcounts start as 1.enetc_flip_rx_buff() figures they're reusable, transfers theserx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), andbumps the refcount to 2. When xdp_do_redirect() later returns an error,we call the no-op enetc_xdp_free(), but we still haven't lost thereference to that page. A copy of it is still at rx_ring->next_to_alloc,but that has refcount 2 (and there are no concurrent owners of it inflight, to drop the refcount). What really kills the system is whenwe'll flip the rx_swbd->page the second time around. With an updatedrefcount of 2, the page will not be reusable and we'll really leak it.Then enetc_new_page() will have to allocate more pages, which will theneventually leak again on further errors from xdp_do_redirect().The problem, summarized, is that we zeroize rx_swbd->page before we'recompletely done with it, and this makes it impossible for the error pathto do something with it.Since the packet is potentially multi-buffer and therefore therx_swbd->page is potentially an array, manual passing of the oldpointers between enetc_flip_rx_buff() and enetc_xdp_free() is a bitdifficult.For the sake of going with a simple solution, we accept the possibilityof racing with xdp_do_redirect(), and we move the flip procedure toexecute only on the redirect success path. By racing, I mean that thepage may be deemed as not reusable by enetc (having a refcount of 0),but there will be no leak in that case, either.Once we accept that, we have something better to do with buffers onXDP_REDIRECT failure. Since we haven't performed half-page flipping yet,we won't, either (and this way, we can avoid enetc_xdp_free()completely, which gives the entire page to the slab allocator).Instead, we'll call enetc_xdp_drop(), which will recycle this half ofthe buffer back to the RX ring.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50569 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Update ipcomp_scratches with NULL when freedCurrently if ipcomp_alloc_scratches() fails to allocate memoryipcomp_scratches holds obsolete address. So when we try to free thepercpu scratches using ipcomp_free_scratches() it tries to vfree nonexistent vm area. Described below:static void * __percpu *ipcomp_alloc_scratches(void){ ... scratches = alloc_percpu(void *); if (!scratches) return NULL;ipcomp_scratches does not know about this allocation failure.Therefore holding the old obsolete address. ...}So when we free,static void ipcomp_free_scratches(void){ ... scratches = ipcomp_scratches;Assigning obsolete address from ipcomp_scratches if (!scratches) return; for_each_possible_cpu(i) vfree(*per_cpu_ptr(scratches, i));Trying to free non existent page, causing warning: trying to vfreeexistent vm area. ...}Fix this breakage by updating ipcomp_scrtches with NULL when scratchesis freed

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-5981 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability was found that the response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from response times of ciphertexts with correct PKCS#1 v1.5 padding.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.59.1).

CVE-2023-7008 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability was found in systemd-resolved. This issue may allow systemd-resolved to accept records of DNSSEC-signed domains even when they have no signature, allowing man-in-the-middles (or the upstream DNS resolver) to manipulate records.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libsystemd0 > 0-0 (version in image is 249.17-150400.8.55.1).

CVE-2024-0553 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability was found in GnuTLS. The response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from the response times of ciphertexts with correct PKCS#1 v1.5 padding. This issue may allow a remote attacker to perform a timing side-channel attack in the RSA-PSK key exchange, potentially leading to the leakage of sensitive data. CVE-2024-0553 is designated as an incomplete resolution for CVE-2023-5981.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.59.1).

CVE-2024-0567 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability was found in GnuTLS, where a cockpit (which uses gnuTLS) rejects a certificate chain with distributed trust. This issue occurs when validating a certificate chain with cockpit-certificate-ensure. This flaw allows an unauthenticated, remote client or attacker to initiate a denial of service attack.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.59.1).

CVE-2024-47081 Severity: Moderate CVSS3 score: 5.9

Description: Requests is a HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-requests > 0-0 (version in image is 2.31.0-150400.6.21.1).

CVE-2024-50602 Severity: Moderate CVSS3 score: 5.9

Description: An issue was discovered in libexpat before 2.6.4. There is a crash within the XML_ResumeParser function because XML_StopParser can stop/suspend an unstarted parser.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.37.1).

CVE-2024-56703 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix soft lockups in fib6_select_path under high next hop churnSoft lockups have been observed on a cluster of Linux-based edge routerslocated in a highly dynamic environment. Using the `bird` service, theserouters continuously update BGP-advertised routes due to frequentlychanging nexthop destinations, while also managing significant IPv6traffic. The lockups occur during the traversal of the multipathcircular linked-list in the `fib6_select_path` function, particularlywhile iterating through the siblings in the list. The issue typicallyarises when the nodes of the linked list are unexpectedly deletedconcurrently on a different core-indicated by their 'next' and'previous' elements pointing back to the node itself and their referencecount dropping to zero. This results in an infinite loop, leading to asoft lockup that triggers a system panic via the watchdog timer.Apply RCU primitives in the problematic code sections to resolve theissue. Where necessary, update the references to fib6_siblings toannotate or use the RCU APIs.Include a test script that reproduces the issue. The scriptperiodically updates the routing table while generating a heavy loadof outgoing IPv6 traffic through multiple iperf3 clients. Itconsistently induces infinite soft lockups within a couple of minutes.Kernel log: 0 [ffffbd13003e8d30] machine_kexec at ffffffff8ceaf3eb 1 [ffffbd13003e8d90] __crash_kexec at ffffffff8d0120e3 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4 3 [ffffbd13003e8ed8] watchdog_timer_fn at ffffffff8d05cb03 4 [ffffbd13003e8f08] __hrtimer_run_queues at ffffffff8cfec62f 5 [ffffbd13003e8f70] hrtimer_interrupt at ffffffff8cfed756 6 [ffffbd13003e8fd0] __sysvec_apic_timer_interrupt at ffffffff8cea01af 7 [ffffbd13003e8ff0] sysvec_apic_timer_interrupt at ffffffff8df1b83d-- -- 8 [ffffbd13003d3708] asm_sysvec_apic_timer_interrupt at ffffffff8e000ecb [exception RIP: fib6_select_path+299] RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287 RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000 RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618 RBP: ffffbd13003d3800 R8: 0000000000000000 R9: ffff975850b40200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffbd13003d3830 R13: ffff975850b436a8 R14: ffff975850b43600 R15: 0000000000000007 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 9 [ffffbd13003d3808] ip6_pol_route at ffffffff8ddb030c10 [ffffbd13003d3888] ip6_pol_route_input at ffffffff8ddb068c11 [ffffbd13003d3898] fib6_rule_lookup at ffffffff8ddf02b512 [ffffbd13003d3928] ip6_route_input at ffffffff8ddb0f4713 [ffffbd13003d3a18] ip6_rcv_finish_core.constprop.0 at ffffffff8dd950d014 [ffffbd13003d3a30] ip6_list_rcv_finish.constprop.0 at ffffffff8dd9627415 [ffffbd13003d3a98] ip6_sublist_rcv at ffffffff8dd9647416 [ffffbd13003d3af8] ipv6_list_rcv at ffffffff8dd9661517 [ffffbd13003d3b60] __netif_receive_skb_list_core at ffffffff8dc16fec18 [ffffbd13003d3be0] netif_receive_skb_list_internal at ffffffff8dc176b319 [ffffbd13003d3c50] napi_gro_receive at ffffffff8dc565b920 [ffffbd13003d3c80] ice_receive_skb at ffffffffc087e4f5 [ice]21 [ffffbd13003d3c90] ice_clean_rx_irq at ffffffffc0881b80 [ice]22 [ffffbd13003d3d20] ice_napi_poll at ffffffffc088232f [ice]23 [ffffbd13003d3d80] __napi_poll at ffffffff8dc1800024 [ffffbd13003d3db8] net_rx_action at ffffffff8dc1858125 [ffffbd13003d3e40] __do_softirq at ffffffff8df352e926 [ffffbd13003d3eb0] run_ksoftirqd at ffffffff8ceffe4727 [ffffbd13003d3ec0] smpboot_thread_fn at ffffffff8cf36a3028 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f29 [ffffbd13003d3f28] ret_from_fork at ffffffff8ce5fa6430 [ffffbd13003d3f50] ret_from_fork_asm at ffffffff8ce03cbb

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56718 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: protect link down work from execute after lgr freedlink down work may be scheduled before lgr freed but executeafter lgr freed, which may result in crash. So it is need tohold a reference before shedule link down work, and put thereference after work executed or canceled.The relevant crash call stack as follows: list_del corruption. prev->next should be ffffb638c9c0fe20, but was 0000000000000000 ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:51! invalid opcode: 0000 [#1] SMP NOPTI CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014 Workqueue: events smc_link_down_work [smc] RIP: 0010:__list_del_entry_valid.cold+0x31/0x47 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000 RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0 FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: rwsem_down_write_slowpath+0x17e/0x470 smc_link_down_work+0x3c/0x60 [smc] process_one_work+0x1ac/0x350 worker_thread+0x49/0x2f0 ? rescuer_thread+0x360/0x360 kthread+0x118/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x1f/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21959 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conncount: Fully initialize struct nf_conncount_tuple in insert_tree()Since commit b36e4523d4d5 ("netfilter: nf_conncount: fix garbagecollection confirm race"), `cpu` and `jiffies32` were introduced tothe struct nf_conncount_tuple.The commit made nf_conncount_add() initialize `conn->cpu` and`conn->jiffies32` when allocating the struct.In contrast, count_tree() was not changed to initialize them.By commit 34848d5c896e ("netfilter: nf_conncount: Split insert andtraversal"), count_tree() was split and the relevant allocationcode now resides in insert_tree().Initialize `conn->cpu` and `conn->jiffies32` in insert_tree().BUG: KMSAN: uninit-value in find_or_evict net/netfilter/nf_conncount.c:117 [inline]BUG: KMSAN: uninit-value in __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 find_or_evict net/netfilter/nf_conncount.c:117 [inline] __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 count_tree net/netfilter/nf_conncount.c:438 [inline] nf_conncount_count+0x82f/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [inline] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [inline] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ipv4/ip_input.c:669 __netif_receive_skb_list_ptype net/core/dev.c:5936 [inline] __netif_receive_skb_list_core+0x15c5/0x1670 net/core/dev.c:5983 __netif_receive_skb_list net/core/dev.c:6035 [inline] netif_receive_skb_list_internal+0x1085/0x1700 net/core/dev.c:6126 netif_receive_skb_list+0x5a/0x460 net/core/dev.c:6178 xdp_recv_frames net/bpf/test_run.c:280 [inline] xdp_test_run_batch net/bpf/test_run.c:361 [inline] bpf_test_run_xdp_live+0x2e86/0x3480 net/bpf/test_run.c:390 bpf_prog_test_run_xdp+0xf1d/0x1ae0 net/bpf/test_run.c:1316 bpf_prog_test_run+0x5e5/0xa30 kernel/bpf/syscall.c:4407 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813 __do_sys_bpf kernel/bpf/syscall.c:5902 [inline] __se_sys_bpf kernel/bpf/syscall.c:5900 [inline] __ia32_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5900 ia32_sys_call+0x394d/0x4180 arch/x86/include/generated/asm/syscalls_32.h:358 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/common.c:387 do_fast_syscall_32+0x38/0x80 arch/x86/entry/common.c:412 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:450 entry_SYSENTER_compat_after_hwframe+0x84/0x8eUninit was created at: slab_post_alloc_hook mm/slub.c:4121 [inline] slab_alloc_node mm/slub.c:4164 [inline] kmem_cache_alloc_noprof+0x915/0xe10 mm/slub.c:4171 insert_tree net/netfilter/nf_conncount.c:372 [inline] count_tree net/netfilter/nf_conncount.c:450 [inline] nf_conncount_count+0x1415/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [inline] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [inline] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ip---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22063 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 socketsWhen calling netlbl_conn_setattr(), addr->sa_family is usedto determine the function behavior. If sk is an IPv4 socket,but the connect function is called with an IPv6 address,the function calipso_sock_setattr() is triggered.Inside this function, the following code is executed:sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;Since sk is an IPv4 socket, pinet6 is NULL, leading to anull pointer dereference.This patch fixes the issue by checking if inet6_sk(sk)returns a NULL pointer before accessing pinet6.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-3360 Severity: Moderate CVSS3 score: 5.9

Description: A flaw was found in GLib. An integer overflow and buffer under-read occur when parsing a long invalid ISO 8601 timestamp with the g_date_time_new_from_iso8601() function.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libglib-2_0-0 > 0-0 (version in image is 2.70.5-150400.3.34.1).

CVE-2025-3576 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability in the MIT Kerberos implementation allows GSSAPI-protected messages using RC4-HMAC-MD5 to be spoofed due to weaknesses in the MD5 checksum design. If RC4 is preferred over stronger encryption types, an attacker could exploit MD5 collisions to forge message integrity codes. This may lead to unauthorized message tampering.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
krb5 > 0-0 (version in image is 1.19.2-150400.3.18.1).

CVE-2025-38035 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: don't restore null sk_state_changequeue->state_change is set as part of nvmet_tcp_set_queue_sock(), but ifthe TCP connection isn't established when nvmet_tcp_set_queue_sock() iscalled then queue->state_change isn't set and sock->sk->sk_state_changeisn't replaced.As such we don't need to restore sock->sk->sk_state_change ifqueue->state_change is NULL.This avoids NULL pointer dereferences such as this:[ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode[ 286.463796][ C0] #PF: error_code(0x0010) - not-present page[ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0[ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI[ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)[ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014[ 286.467147][ C0] RIP: 0010:0x0[ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.[ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246[ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43[ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100[ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c[ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3[ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268[ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000[ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0[ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400[ 286.475453][ C0] Call Trace:[ 286.476102][ C0] [ 286.476719][ C0] tcp_fin+0x2bb/0x440[ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60[ 286.478174][ C0] ? __build_skb_around+0x234/0x330[ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0[ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10[ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0[ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90[ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30[ 286.482769][ C0] ? ktime_get+0x66/0x150[ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0[ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050[ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0[ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0[ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10[ 286.486917][ C0] ? lock_release+0x217/0x2c0[ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0[ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30[ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0[ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0[ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10[ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10[ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack][ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0[ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370[ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420[ 286.494268][ C0] ip_local_deliver+0x168/0x430[ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10[ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10[ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20[ 286.496806][ C0] ? lock_release+0x217/0x2c0[ 286.497414][ C0] ip_rcv+0x455/0x6e0[ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10[ ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
cups-config > 0-0 (version in image is 2.2.7-150000.3.86.1).

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
gpg2 > 0-0 (version in image is 2.2.27-150300.3.19.1).

CVE-2026-0990 Severity: Moderate CVSS3 score: 5.9

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.55.1).

CVE-2026-23277 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmitteql_master_xmit() calls netdev_start_xmit(skb, slave) to transmitthrough slave devices, but does not update skb->dev to the slave devicebeforehand.When a gretap tunnel is a TEQL slave, the transmit path reachesiptunnel_xmit() which saves dev = skb->dev (still pointing to teql0master) and later calls iptunnel_xmit_stats(dev, pkt_len). Thisfunction does: get_cpu_ptr(dev->tstats)Since teql_master_setup() does not set dev->pcpu_stat_type toNETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstatsfor teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computesNULL + __per_cpu_offset[cpu], resulting in a page fault. BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206)Fix this by setting skb->dev = slave before callingnetdev_start_xmit(), so that tunnel xmit functions see the correctslave device with properly allocated tstats.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23293 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabledWhen booting with the 'ipv6.disable=1' parameter, the nd_tbl is neverinitialized because inet6_init() exits before ndisc_init() is calledwhich initializes it. If an IPv6 packet is injected into the interface,route_shortcircuit() is called and a NULL pointer dereference happens onneigh_lookup(). BUG: kernel NULL pointer dereference, address: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neigh_lookup+0x20/0x270 [...] Call Trace: vxlan_xmit+0x638/0x1ef0 [vxlan] dev_hard_start_xmit+0x9e/0x2e0 __dev_queue_xmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x12f/0x1590 entry_SYSCALL_64_after_hwframe+0x76/0x7eFix this by adding an early check on route_shortcircuit() when protocolis ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here becauseVXLAN can be built-in even when IPv6 is built as a module.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23398 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:icmp: fix NULL pointer dereference in icmp_tag_validation()icmp_tag_validation() unconditionally dereferences the result ofrcu_dereference(inet_protos[proto]) without checking for NULL.The inet_protos[] array is sparse -- only about 15 of 256 protocolnumbers have registered handlers. When ip_no_pmtu_disc is set to 3(hardened PMTU mode) and the kernel receives an ICMP FragmentationNeeded error with a quoted inner IP header containing an unregisteredprotocol number, the NULL dereference causes a kernel panic insoftirq context. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) Add a NULL check before accessing icmp_strict_tag_validation. If theprotocol has no registered handler, return false since it cannotperform strict tag validation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-40355 Severity: Moderate CVSS3 score: 5.9

Description: In MIT Kerberos 5 (aka krb5) before 1.22.3, there is a NULL pointer dereference if an application calls gss_accept_sec_context() on a system with a NegoEx mechanism registered in /etc/gss/mech. An unauthenticated remote attacker can trigger this, causing the process to terminate in parse_nego_message.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
krb5 > 0-0 (version in image is 1.19.2-150400.3.18.1).

CVE-2026-40356 Severity: Moderate CVSS3 score: 5.9

Description: In MIT Kerberos 5 (aka krb5) before 1.22.3, there is an integer underflow and resultant out-of-bounds read if an application calls gss_accept_sec_context() on a system with a NegoEx mechanism registered in /etc/gss/mech. An unauthenticated remote attacker can trigger this, possibly causing the process to terminate in parse_message.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
krb5 > 0-0 (version in image is 1.19.2-150400.3.18.1).

CVE-2026-43411 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix divide-by-zero in tipc_sk_filter_connect()A user can set conn_timeout to any value viasetsockopt(TIPC_CONN_TIMEOUT), including values less than 4. When aSYN is rejected with TIPC_ERR_OVERLOAD and the retry path intipc_sk_filter_connect() executes: delay %= (tsk->conn_timeout / 4);If conn_timeout is in the range [0, 3], the integer division yields 0,and the modulo operation triggers a divide-by-zero exception, causing akernel oops/panic.Fix this by clamping conn_timeout to a minimum of 4 at the point of usein tipc_sk_filter_connect().Oops: divide error: 0000 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+RIP: 0010:tipc_sk_filter_rcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362)Call Trace: tipc_sk_backlog_rcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406) __release_sock (include/net/sock.h:1185 net/core/sock.c:3213) release_sock (net/core/sock.c:3797) tipc_connect (net/tipc/socket.c:2570) __sys_connect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45841 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULOnf_osf_match_one() computes ctx->window % f->wss.val in theOSF_WSS_MODULO branch with no guard for f->wss.val == 0. ACAP_NET_ADMIN user can add such a fingerprint via nfnetlink; asubsequent matching TCP SYN divides by zero and panics the kernel.Reject the bogus fingerprint in nfnl_osf_add_callback() above theper-option for-loop. f->wss is per-fingerprint, not per-option, sothe check must run regardless of f->opt_num (including 0). Alsoreject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats thatas "should not happen".Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:220) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:348) nf_hook_slow (net/netfilter/core.c:622) ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv (include/linux/skbuff.h:1162) __netif_receive_skb_one_core (net/core/dev.c:6181) process_backlog (net/core/dev.c:6642) __napi_poll (net/core/dev.c:7710) net_rx_action (net/core/dev.c:7945) handle_softirqs (kernel/softirq.c:622)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45846 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()bareudp_fill_metadata_dst() passes bareudp->sock toudp_tunnel6_dst_lookup() in the IPv6 path without a NULL check.The socket is only created in bareudp_open() and NULLed inbareudp_stop(), so calling this function while the device is downtriggers a NULL dereference via sock->sk. BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160) Call Trace: bareudp_fill_metadata_dst (drivers/net/bareudp.c:532) do_execute_actions (net/openvswitch/actions.c:901) ovs_execute_actions (net/openvswitch/actions.c:1589) ovs_packet_cmd_execute (net/openvswitch/datapath.c:700) genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1209) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Add a NULL check returning -ESHUTDOWN, consistent with the xmit pathsin the same driver.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-46031 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:net: ks8851: Reinstate disabling of BHs around IRQ handlerIf the driver executes ks8851_irq() AND a TX packet has been sent, thenthe driver enables TX queue via netif_wake_queue() which schedules TXsoftirq to queue packets for this device.If CONFIG_PREEMPT_RT=y is set AND a packet has also been received bythe MAC, then ks8851_rx_pkts() calls netdev_alloc_skb_ip_align() toallocate SKBs for the received packets. If netdev_alloc_skb_ip_align()is called with BH enabled, then local_bh_enable() at the end ofnetdev_alloc_skb_ip_align() will trigger the pending softirq processing,which may ultimately call the .xmit callback ks8851_start_xmit_par().The ks8851_start_xmit_par() will try to lock struct ks8851_net_par.lock spinlock, which is already locked by ks8851_irq() from whichks8851_start_xmit_par() was called. This leads to a deadlock, whichis reported by the kernel, including a trace listed below.If CONFIG_PREEMPT_RT is not set, then since commit 0913ec336a6c0("net: ks8851: Fix deadlock with the SPI chip variant") the deadlockcan also be triggered without received packet in the RX FIFO. Thepending softirqs will be processed on return fromspin_unlock_bh(&ks->statelock) in ks8851_irq(), which triggers thedeadlock as well.Fix the problem by disabling BH around critical sections, including theIRQ handler, thus preventing the net_tx_action() softirq from triggeringduring these critical sections. The net_tx_action() softirq is triggeredonce BH are re-enabled and at the end of the IRQ handler, once all theother IRQ handler actions have been completed. __schedule from schedule_rtlock+0x1c/0x34 schedule_rtlock from rtlock_slowlock_locked+0x548/0x904 rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8 ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44 netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188 dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c sch_direct_xmit from __qdisc_run+0x1f8/0x4ec __qdisc_run from qdisc_run+0x1c/0x28 qdisc_run from net_tx_action+0x1f0/0x268 net_tx_action from handle_softirqs+0x1a4/0x270 handle_softirqs from __local_bh_enable_ip+0xcc/0xe0 __local_bh_enable_ip from __alloc_skb+0xd8/0x128 __alloc_skb from __netdev_alloc_skb+0x3c/0x19c __netdev_alloc_skb from ks8851_irq+0x388/0x4d4 ks8851_irq from irq_thread_fn+0x24/0x64 irq_thread_fn from irq_thread+0x178/0x28c irq_thread from kthread+0x12c/0x138 kthread from ret_from_fork+0x14/0x28

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-46137 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: ADD_ADDR rtx: fix potential data-raceThis mptcp_pm_add_timer() helper is executed as a timer callback insoftirq context. To avoid any data races, the socket lock needs to beheld with bh_lock_sock().If the socket is in use, retry again soon after, similar to what is donewith the keepalive timer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-52946 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signalingA SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur insend_sigio() and send_sigurg() when a process group receives a signal.When FASYNC is configured for a process group (PIDTYPE_PGID), bothfunctions use read_lock(&tasklist_lock) to traverse the task list.However, they are frequently called from softirq context:- send_sigio() via input_inject_event -> kill_fasync- send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ)The deadlock is caused by the rwlock writer fairness mechanism:1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait().2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in fork() or exit() and spins, which blocks all new readers.3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).4. The softirq calls send_sigurg() and attempts to acquire read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.Since PID hashing and do_each_pid_task() traversals are alreadyRCU-protected, the read_lock on tasklist_lock is no longer strictlyrequired for safe traversal. Fix this by replacing tasklist_lock withrcu_read_lock(), aligning the process group signaling path with thesingle-PID path. This also mitigates a potential remote denial ofservice vector via TCP URG packets.Lockdep splat:=====================================================WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected[...]Chain exists of: &dev->event_lock --> &f_owner->lock --> tasklist_lockPossible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklist_lock); local_irq_disable(); lock(&dev->event_lock); lock(&f_owner->lock); lock(&dev->event_lock);*** DEADLOCK ***

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-52963 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Bound MIDI endpoint descriptor scanssnd_usbmidi_get_ms_info() validates the internal MIDIStreaming endpointdescriptor size before using baAssocJackID[], but the descriptor walker canstill return a class-specific endpoint descriptor whose bLength exceeds theremaining bytes in the endpoint-extra scan.That leaves later flexible-array reads bounded by bLength, but not by theremaining bytes in the endpoint-extra scan.Stop walking when bLength is zero orextends past the remaining endpoint-extra scan.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53043 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2/dlm: validate qr_numregions in dlm_match_regions()Patch series "ocfs2/dlm: fix two bugs in dlm_match_regions()".In dlm_match_regions(), the qr_numregions field from a DLM_QUERY_REGIONnetwork message is used to drive loops over the qr_regions buffer withoutsufficient validation. This series fixes two issues:- Patch 1 adds a bounds check to reject messages where qr_numregions exceeds O2NM_MAX_REGIONS. The o2net layer only validates message byte length; it does not constrain field values, so a crafted message can set qr_numregions up to 255 and trigger out-of-bounds reads past the 1024-byte qr_regions buffer.- Patch 2 fixes an off-by-one in the local-vs-remote comparison loop, which uses '<=' instead of '<', reading one entry past the valid range even when qr_numregions is within bounds.This patch (of 2):The qr_numregions field from a DLM_QUERY_REGION network message is useddirectly as loop bounds in dlm_match_regions() without checking againstO2NM_MAX_REGIONS. Since qr_regions is sized for at most O2NM_MAX_REGIONS(32) entries, a crafted message with qr_numregions > 32 causesout-of-bounds reads past the qr_regions buffer.Add a bounds check for qr_numregions before entering the loops.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53070 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: disable BH before calling udp_tunnel_xmit_skb()udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run withBH disabled. After commit 6f1a9140ecda ("add xmit recursion limit totunnel xmit functions"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit()dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU.Without local_bh_disable(), the context may move between CPUs, which canbreak the inc/dec pairing. This may lead to incorrect recursion leveldetection and cause packets to be dropped in ip(6)_tunnel_xmit() or__dev_queue_xmit().Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths.In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s- without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver- with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53086 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:net: bcmgenet: fix racing timeout handlerThe bcmgenet_timeout handler tries to take down all tx queues whena single queue times out. This is over zealous and causes many raceconditions with queues that are still chugging along. Instead letsonly restart the timed out queue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-54411 Severity: Moderate CVSS3 score: 5.9

Description: Linux-PAM through 1.7.2 contains an observable timing discrepancy (CWE-208) in the pam_userdb module's plaintext-password comparison path in modules/pam_userdb/pam_userdb.c that allows a local or network-adjacent attacker able to repeatedly drive authentication through a calling service to recover the plaintext password of a target account by measuring response-timing differences. The comparison uses strncmp() (or strncasecmp() when PAM_ICASE_ARG is set) preceded by a length-equality check, so the time to reject a candidate depends on the index of the first differing byte and on whether the candidate's length matches the stored password, leaking the password length and individual prefix bytes. The vulnerable path is reached when the administrator configures pam_userdb with crypt=none, with an unrecognized crypt method, or without a crypt= argument, causing the module to store and compare credentials in plaintext.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
pam > 0-0 (version in image is 1.3.0-150000.6.86.1).

CVE-2026-5450 Severity: Moderate CVSS3 score: 5.9

Description: Calling the scanf family of functions with a %mc (malloc'd character match) in the GNU C Library version 2.7 to version 2.43 with a format width specifier with an explicit width greater than 1024 could result in a one byte heap buffer overflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glibc < 2.31-150300.101.1 (version in image is 2.31-150300.98.1).

CVE-2026-7168 Severity: Moderate CVSS3 score: 5.9

Description: Successfully using libcurl to do a transfer over a specific HTTP proxy(`proxyA`) with **Digest** authentication and then changing the proxy host toa second one (`proxyB`) for a second transfer, reusing the same handle, makeslibcurl wrongly pass on the `Proxy-Authorization:` header field meant for`proxyA`, to `proxyB`.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.83.1).

CVE-2026-7383 Severity: Moderate CVSS3 score: 5.9

Description: Issue summary: A signed integer overflow when sizing the destinationbuffer for Unicode output in ASN1_mbstring_ncopy() can lead to a heapbuffer overflow.Impact summary: A heap buffer overflow may lead to a crash or possiblyattacker controlled code execution or other undefined behaviour.In ASN1_mbstring_copy() and ASN1_mbstring_ncopy() the destinationsize for Unicode output is computed in a signed int: by left shiftof the input character count for BMPSTRING (UTF-16) andUNIVERSALSTRING (UTF-32), and by summing per-character byte countsfor UTF8STRING. The calculation overflows when the input reachesaround 2^30 characters. In the worst case (UNIVERSALSTRING at 2^30characters) the size wraps to zero, OPENSSL_malloc(1) is called, andthe subsequent character copy writes several gigabytes past theone-byte allocation.X.509 certificate processing routes through ASN1_STRING_set_by_NID(),whose DIRSTRING_TYPE mask excludes UNIVERSALSTRING and whose per-NIDsize limits cap the input length; no network protocol orcertificate-handling path in OpenSSL exercises the overflow.Triggering the bug requires an application that callsASN1_mbstring_copy() or ASN1_mbstring_ncopy() directly, or registersa custom string type via ASN1_STRING_TABLE_add(), withattacker-controlled input on the order of half a gigabyte or more.For these reasons this issue was assigned Low severity.The FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected bythis issue, as the affected code is outside the OpenSSL FIPS moduleboundary.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libopenssl1_1 < 1.1.1l-150400.7.96.2 (version in image is 1.1.1l-150400.7.93.1).

CVE-2022-49939 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:binder: fix UAF of ref->proc caused by race conditionA transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment thereference for a node. In this case, the target proc normally releasesthe failed reference upon close as expected. However, if the target isdying in parallel the call will race with binder_deferred_release(), sothe target could have released all of its references by now leaving thecleanup of the new failed reference unhandled.The transaction then ends and the target proc gets released making theref->proc now a dangling pointer. Later on, ref->node is closed and weattempt to take spin_lock(&ref->proc->inner_lock), which leads to theuse-after-free bug reported below. Let's fix this by cleaning up thefailed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53034 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_transThere is a kernel API ntb_mw_clear_trans() would pass 0 to both addr andsize. This would make xlate_pos negative.[ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000[ 23.734158] ================================================================================[ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7[ 23.734418] shift exponent -1 is negativeEnsuring xlate_pos is a positive or zero before BIT.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53536 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:blk-crypto: make blk_crypto_evict_key() more robustIf blk_crypto_evict_key() sees that the key is still in-use (due to abug) or that ->keyslot_evict failed, it currently just returns whileleaving the key linked into the keyslot management structures.However, blk_crypto_evict_key() is only called in contexts such as inodeeviction where failure is not an option. So actually the callerproceeds with freeing the blk_crypto_key regardless of the return valueof blk_crypto_evict_key().These two assumptions don't match, and the result is that there can be ause-after-free in blk_crypto_reprogram_all_keys() after one of theseerrors occurs. (Note, these errors *shouldn't* happen; we're justtalking about what happens if they do anyway.)Fix this by making blk_crypto_evict_key() unlink the key from thekeyslot management structures even on failure.Also improve some comments.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53629 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:fs: dlm: fix use after free in midcomms commitWhile working on processing dlm message in softirq context I experiencedthe following KASAN use-after-free warning:[ 151.760477] ==================================================================[ 151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347[ 151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828[ 151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014[ 151.768726] Call Trace:[ 151.769277] [ 151.769748] dump_stack_lvl+0x5b/0x86[ 151.770556] print_report+0x180/0x4c8[ 151.771378] ? kasan_complete_mode_report_info+0x7c/0x1e0[ 151.772241] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.773069] kasan_report+0x93/0x1a0[ 151.773668] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.774514] __asan_load4+0x7e/0xa0[ 151.775089] dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.775890] ? create_message.isra.29.constprop.64+0x57/0xc0[ 151.776770] send_common+0x19f/0x1b0[ 151.777342] ? remove_from_waiters+0x60/0x60[ 151.778017] ? lock_downgrade+0x410/0x410[ 151.778648] ? __this_cpu_preempt_check+0x13/0x20[ 151.779421] ? rcu_lockdep_current_cpu_online+0x88/0xc0[ 151.780292] _convert_lock+0x46/0x150[ 151.780893] convert_lock+0x7b/0xc0[ 151.781459] dlm_lock+0x3ac/0x580[ 151.781993] ? 0xffffffffc0540000[ 151.782522] ? torture_stop+0x120/0x120 [dlm_locktorture][ 151.783379] ? dlm_scan_rsbs+0xa70/0xa70[ 151.784003] ? preempt_count_sub+0xd6/0x130[ 151.784661] ? is_module_address+0x47/0x70[ 151.785309] ? torture_stop+0x120/0x120 [dlm_locktorture][ 151.786166] ? 0xffffffffc0540000[ 151.786693] ? lockdep_init_map_type+0xc3/0x360[ 151.787414] ? 0xffffffffc0540000[ 151.787947] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture][ 151.789004] ? torture_stop+0x120/0x120 [dlm_locktorture][ 151.789858] ? 0xffffffffc0540000[ 151.790392] ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture][ 151.791347] ? delay_tsc+0x94/0xc0[ 151.791898] torture_ex_iter+0xc3/0xea [dlm_locktorture][ 151.792735] ? torture_start+0x30/0x30 [dlm_locktorture][ 151.793606] lock_torture+0x177/0x270 [dlm_locktorture][ 151.794448] ? torture_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture][ 151.795539] ? lock_torture_stats+0x80/0x80 [dlm_locktorture][ 151.796476] ? do_raw_spin_lock+0x11e/0x1e0[ 151.797152] ? mark_held_locks+0x34/0xb0[ 151.797784] ? _raw_spin_unlock_irqrestore+0x30/0x70[ 151.798581] ? __kthread_parkme+0x79/0x110[ 151.799246] ? trace_preempt_on+0x2a/0xf0[ 151.799902] ? __kthread_parkme+0x79/0x110[ 151.800579] ? preempt_count_sub+0xd6/0x130[ 151.801271] ? __kasan_check_read+0x11/0x20[ 151.801963] ? __kthread_parkme+0xec/0x110[ 151.802630] ? lock_torture_stats+0x80/0x80 [dlm_locktorture][ 151.803569] kthread+0x192/0x1d0[ 151.804104] ? kthread_complete_and_exit+0x30/0x30[ 151.804881] ret_from_fork+0x1f/0x30[ 151.805480] [ 151.806111] Allocated by task 1347:[ 151.806681] kasan_save_stack+0x26/0x50[ 151.807308] kasan_set_track+0x25/0x30[ 151.807920] kasan_save_alloc_info+0x1e/0x30[ 151.808609] __kasan_slab_alloc+0x63/0x80[ 151.809263] kmem_cache_alloc+0x1ad/0x830[ 151.809916] dlm_allocate_mhandle+0x17/0x20[ 151.810590] dlm_midcomms_get_mhandle+0x96/0x260[ 151.811344] _create_message+0x95/0x180[ 151.811994] create_message.isra.29.constprop.64+0x57/0xc0[ 151.812880] send_common+0x129/0x1b0[ 151.813467] _convert_lock+0x46/0x150[ 151.814074] convert_lock+0x7b/0xc0[ 151.814648] dlm_lock+0x3ac/0x580[ 151.815199] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture][ 151.816258] torture_ex_iter+0xc3/0xea [dlm_locktorture][ 151.817129] lock_t---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53694 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:riscv: ftrace: Fixup panic by disabling preemptionIn RISCV, we must use an AUIPC + JALR pair to encode an immediate,forming a jump that jumps to an address over 4K. This may cause errorsif we want to enable kernel preemption and remove dependency frompatching code with stop_machine(). For example, if a task was switchedout on auipc. And, if we changed the ftrace function before it wasswitched back, then it would jump to an address that has updated 11:0bits mixing with previous XLEN:12 part.p: patched area performed by dynamic ftraceftrace_prologue:p| REG_S ra, -SZREG(sp)p| auipc ra, 0x? ------------> preempted ... change ftrace function ...p| jalr -?(ra) <------------- switched backp| REG_L ra, -SZREG(sp)func: xxx ret

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54176 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: stricter state check in mptcp_workerAs reported by Christoph, the mptcp protocol can run theworker when the relevant msk socket is in an unexpected state:connect()// incoming reset + fastclose// the mptcp worker is scheduledmptcp_disconnect()// msk is now CLOSEDlisten()mptcp_worker()Leading to the following splat:divide error: 0000 [#1] PREEMPT SMPCPU: 1 PID: 21 Comm: kworker/1:0 Not tainted 6.3.0-rc1-gde5e8fd0123c #11Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014Workqueue: events mptcp_workerRIP: 0010:__tcp_select_window+0x22c/0x4b0 net/ipv4/tcp_output.c:3018RSP: 0018:ffffc900000b3c98 EFLAGS: 00010293RAX: 000000000000ffd7 RBX: 000000000000ffd7 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffffffff8214ce97 RDI: 0000000000000004RBP: 000000000000ffd7 R08: 0000000000000004 R09: 0000000000010000R10: 000000000000ffd7 R11: ffff888005afa148 R12: 000000000000ffd7R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000405270 CR3: 000000003011e006 CR4: 0000000000370ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_select_window net/ipv4/tcp_output.c:262 [inline] __tcp_transmit_skb+0x356/0x1280 net/ipv4/tcp_output.c:1345 tcp_transmit_skb net/ipv4/tcp_output.c:1417 [inline] tcp_send_active_reset+0x13e/0x320 net/ipv4/tcp_output.c:3459 mptcp_check_fastclose net/mptcp/protocol.c:2530 [inline] mptcp_worker+0x6c7/0x800 net/mptcp/protocol.c:2705 process_one_work+0x3bd/0x950 kernel/workqueue.c:2390 worker_thread+0x5b/0x610 kernel/workqueue.c:2537 kthread+0x138/0x170 kernel/kthread.c:376 ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308 This change addresses the issue explicitly checking for bad statesbefore running the mptcp worker.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54283 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Address KCSAN report on bpf_lru_listKCSAN reported a data-race when accessing node->ref.Although node->ref does not have to be accurate,take this chance to use a more common READ_ONCE() and WRITE_ONCE()pattern instead of data_race().There is an existing bpf_lru_node_is_ref() and bpf_lru_node_set_ref().This patch also adds bpf_lru_node_clear_ref() to do theWRITE_ONCE(node->ref, 0) also.==================================================================BUG: KCSAN: data-race in __bpf_lru_list_rotate / __htab_lru_percpu_map_update_elemwrite to 0xffff888137038deb of 1 bytes by task 11240 on cpu 1:__bpf_lru_node_move kernel/bpf/bpf_lru_list.c:113 [inline]__bpf_lru_list_rotate_active kernel/bpf/bpf_lru_list.c:149 [inline]__bpf_lru_list_rotate+0x1bf/0x750 kernel/bpf/bpf_lru_list.c:240bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:329 [inline]bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [inline]bpf_lru_pop_free+0x638/0xe20 kernel/bpf/bpf_lru_list.c:499prealloc_lru_pop kernel/bpf/hashtab.c:290 [inline]__htab_lru_percpu_map_update_elem+0xe7/0x820 kernel/bpf/hashtab.c:1316bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534__sys_bpf+0x338/0x810__do_sys_bpf kernel/bpf/syscall.c:5096 [inline]__se_sys_bpf kernel/bpf/syscall.c:5094 [inline]__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff888137038deb of 1 bytes by task 11241 on cpu 0:bpf_lru_node_set_ref kernel/bpf/bpf_lru_list.h:70 [inline]__htab_lru_percpu_map_update_elem+0x2f1/0x820 kernel/bpf/hashtab.c:1332bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534__sys_bpf+0x338/0x810__do_sys_bpf kernel/bpf/syscall.c:5096 [inline]__se_sys_bpf kernel/bpf/syscall.c:5094 [inline]__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x01 -> 0x00Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 11241 Comm: syz-executor.3 Not tainted 6.3.0-rc7-syzkaller-00136-g6a66fdd29ea1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023==================================================================

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41005 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:netpoll: Fix race condition in netpoll_owner_activeKCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) value changed: 0x0000000a -> 0xffffffffThis happens because netpoll_owner_active() needs to check if thecurrent CPU is the owner of the lock, touching napi->poll_ownernon atomically. The ->poll_owner field contains the current CPU holdingthe lock.Use an atomic read to check if the poll owner is the current CPU.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46675 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: core: Prevent USB core invalid event buffer address accessThis commit addresses an issue where the USB core could access aninvalid event buffer address during runtime suspend, potentially causingSMMU faults and other memory issues in Exynos platforms. The problemarises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address.To prevent this hardware quirk on Exynos platforms, this commit ensuresthat the event buffer address is not cleared by software when the USBcore is active during runtime suspend by checking its status beforeclearing the buffer address.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53680 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()Under certain kernel configurations when building with Clang/LLVM, thecompiler does not generate a return or jump as the terminatorinstruction for ip_vs_protocol_init(), triggering the following objtoolwarning during build time: vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()At runtime, this either causes an oops when trying to load the ipvsmodule or a boot-time panic if ipvs is built-in. This same issue hasbeen reported by the Intel kernel test robot previously.Digging deeper into both LLVM and the kernel code reveals this to be aundefined behavior problem. ip_vs_protocol_init() uses a on-stack bufferof 64 chars to store the registered protocol names and leaves ituninitialized after definition. The function calls strnlen() whenconcatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCEstrnlen() performs an extra step to check whether the last byte of theinput char buffer is a null character (commit 3009f891bb9f ("fortify:Allow strlen() and strnlen() to pass compile-time known lengths")).This, together with possibly other configurations, cause the followingIR to be generated: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 { %1 = alloca [64 x i8], align 16 ... 14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23 20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ... 23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... }The above code calculates the address of the last char in the buffer(value %15) and then loads from it (value %16). Because the buffer isnever initialized, the LLVM GVN pass marks value %16 as undefined: %13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17This gives later passes (SCCP, in particular) more DCE opportunities bypropagating the undef value further, and eventually removes everythingafter the load on the uninitialized stack location: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 { %1 = alloca [64 x i8], align 16 ... 12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable }In this way, the generated native code will just fall through to thenext function, as LLVM does not generate any code for the unreachable IRinstruction and leaves the function without a terminator.Zero the on-stack buffer to avoid this possible UB.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37903 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix slab-use-after-free in hdcpThe HDCP code in amdgpu_dm_hdcp.c copies pointers to amdgpu_dm_connectorobjects without incrementing the kref reference counts. When using aUSB-C dock, and the dock is unplugged, the correspondingamdgpu_dm_connector objects are freed, creating dangling pointers in theHDCP code. When the dock is plugged back, the dangling pointers aredereferenced, resulting in a slab-use-after-free:[ 66.775837] BUG: KASAN: slab-use-after-free in event_property_validate+0x42f/0x6c0 [amdgpu][ 66.776171] Read of size 4 at addr ffff888127804120 by task kworker/0:1/10[ 66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.14.0-rc7-00180-g54505f727a38-dirty #233[ 66.776183] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024[ 66.776186] Workqueue: events event_property_validate [amdgpu][ 66.776494] Call Trace:[ 66.776496] [ 66.776497] dump_stack_lvl+0x70/0xa0[ 66.776504] print_report+0x175/0x555[ 66.776507] ? __virt_addr_valid+0x243/0x450[ 66.776510] ? kasan_complete_mode_report_info+0x66/0x1c0[ 66.776515] kasan_report+0xeb/0x1c0[ 66.776518] ? event_property_validate+0x42f/0x6c0 [amdgpu][ 66.776819] ? event_property_validate+0x42f/0x6c0 [amdgpu][ 66.777121] __asan_report_load4_noabort+0x14/0x20[ 66.777124] event_property_validate+0x42f/0x6c0 [amdgpu][ 66.777342] ? __lock_acquire+0x6b40/0x6b40[ 66.777347] ? enable_assr+0x250/0x250 [amdgpu][ 66.777571] process_one_work+0x86b/0x1510[ 66.777575] ? pwq_dec_nr_in_flight+0xcf0/0xcf0[ 66.777578] ? assign_work+0x16b/0x280[ 66.777580] ? lock_is_held_type+0xa3/0x130[ 66.777583] worker_thread+0x5c0/0xfa0[ 66.777587] ? process_one_work+0x1510/0x1510[ 66.777588] kthread+0x3a2/0x840[ 66.777591] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777594] ? trace_hardirqs_on+0x4f/0x60[ 66.777597] ? _raw_spin_unlock_irq+0x27/0x60[ 66.777599] ? calculate_sigpending+0x77/0xa0[ 66.777602] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777605] ret_from_fork+0x40/0x90[ 66.777607] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777609] ret_from_fork_asm+0x11/0x20[ 66.777614] [ 66.777643] Allocated by task 10:[ 66.777646] kasan_save_stack+0x39/0x60[ 66.777649] kasan_save_track+0x14/0x40[ 66.777652] kasan_save_alloc_info+0x37/0x50[ 66.777655] __kasan_kmalloc+0xbb/0xc0[ 66.777658] __kmalloc_cache_noprof+0x1c8/0x4b0[ 66.777661] dm_dp_add_mst_connector+0xdd/0x5c0 [amdgpu][ 66.777880] drm_dp_mst_port_add_connector+0x47e/0x770 [drm_display_helper][ 66.777892] drm_dp_send_link_address+0x1554/0x2bf0 [drm_display_helper][ 66.777901] drm_dp_check_and_send_link_address+0x187/0x1f0 [drm_display_helper][ 66.777909] drm_dp_mst_link_probe_work+0x2b8/0x410 [drm_display_helper][ 66.777917] process_one_work+0x86b/0x1510[ 66.777919] worker_thread+0x5c0/0xfa0[ 66.777922] kthread+0x3a2/0x840[ 66.777925] ret_from_fork+0x40/0x90[ 66.777927] ret_from_fork_asm+0x11/0x20[ 66.777932] Freed by task 1713:[ 66.777935] kasan_save_stack+0x39/0x60[ 66.777938] kasan_save_track+0x14/0x40[ 66.777940] kasan_save_free_info+0x3b/0x60[ 66.777944] __kasan_slab_free+0x52/0x70[ 66.777946] kfree+0x13f/0x4b0[ 66.777949] dm_dp_mst_connector_destroy+0xfa/0x150 [amdgpu][ 66.778179] drm_connector_free+0x7d/0xb0[ 66.778184] drm_mode_object_put.part.0+0xee/0x160[ 66.778188] drm_mode_object_put+0x37/0x50[ 66.778191] drm_atomic_state_default_clear+0x220/0xd60[ 66.778194] __drm_atomic_state_free+0x16e/0x2a0[ 66.778197] drm_mode_atomic_ioctl+0x15ed/0x2ba0[ 66.778200] drm_ioctl_kernel+0x17a/0x310[ 66.778203] drm_ioctl+0x584/0xd10[ 66.778206] amdgpu_drm_ioctl+0xd2/0x1c0 [amdgpu][ 66.778375] __x64_sys_ioctl+0x139/0x1a0[ 66.778378] x64_sys_call+0xee7/0xfb0[ 66.778381] ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38005 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: k3-udma: Add missing lockingRecent kernels complain about a missing lock in k3-udma.c when the lockvalidator is enabled:[ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238[ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28[ 4.144867] Hardware name: pp-v12 (DT)[ 4.148648] Workqueue: events udma_check_tx_completion[ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 4.160834] pc : udma_start.isra.0+0x34/0x238[ 4.165227] lr : udma_start.isra.0+0x30/0x238[ 4.169618] sp : ffffffc083cabcf0[ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005[ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000[ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670[ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030[ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048[ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001[ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68[ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8[ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000[ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000[ 4.244986] Call trace:[ 4.247463] udma_start.isra.0+0x34/0x238[ 4.251509] udma_check_tx_completion+0xd0/0xdc[ 4.256076] process_one_work+0x244/0x3fc[ 4.260129] process_scheduled_works+0x6c/0x74[ 4.264610] worker_thread+0x150/0x1dc[ 4.268398] kthread+0xd8/0xe8[ 4.271492] ret_from_fork+0x10/0x20[ 4.275107] irq event stamp: 220[ 4.278363] hardirqs last enabled at (219): [] _raw_spin_unlock_irq+0x38/0x50[ 4.287183] hardirqs last disabled at (220): [] el1_dbg+0x24/0x50[ 4.294879] softirqs last enabled at (182): [] handle_softirqs+0x1c0/0x3cc[ 4.303437] softirqs last disabled at (177): [] __do_softirq+0x1c/0x28[ 4.311559] ---[ end trace 0000000000000000 ]---This commit adds the missing locking.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38230 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: validate AG parameters in dbMount() to prevent crashesValidate db_agheight, db_agwidth, and db_agstart in dbMount to catchcorrupted metadata early and avoid undefined behavior in dbAllocAG.Limits are derived from L2LPERCTL, LPERCTL/MAXAG, and CTLTREESIZE:- agheight: 0 to L2LPERCTL/2 (0 to 5) ensures shift (L2LPERCTL - 2*agheight) >= 0.- agwidth: 1 to min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight)) ensures agperlev >= 1. - Ranges: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5). - LPERCTL/MAXAG = 1024/128 = 8 limits leaves per AG; 2^(10 - 2*agheight) prevents division to 0.- agstart: 0 to CTLTREESIZE-1 - agwidth*(MAXAG-1) keeps ti within stree (size 1365). - Ranges: 0-1237 (agwidth 1), 0-348 (agwidth 8).UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:1400:9shift exponent -335544310 is negativeCPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 Not tainted 6.14.0-rc5-syzkaller #0Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 dbAllocAG+0x1087/0x10b0 fs/jfs/jfs_dmap.c:1400 dbDiscardAG+0x352/0xa20 fs/jfs/jfs_dmap.c:1613 jfs_ioc_trim+0x45a/0x6b0 fs/jfs/jfs_discard.c:105 jfs_ioctl+0x2cd/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 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/0x7fFound by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23193 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count()In iscsit_dec_session_usage_count(), the function calls complete() whileholding the sess->session_usage_lock. Similar to the connection usage countlogic, the waiter signaled by complete() (e.g., in the session releasepath) may wake up and free the iscsit_session structure immediately.This creates a race condition where the current thread may attempt toexecute spin_unlock_bh() on a session structure that has already beendeallocated, resulting in a KASAN slab-use-after-free.To resolve this, release the session_usage_lock before calling complete()to ensure all dereferences of the sess pointer are finished before thewaiter is allowed to proceed with deallocation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23230 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: split cached_fid bitfields to avoid shared-byte RMW racesis_open, has_lease and on_list are stored in the same bitfield byte instruct cached_fid but are updated in different code paths that may runconcurrently. Bitfield assignments generate byte read-modify-writeoperations (e.g. `orb $mask, addr` on x86_64), so updating one flag canrestore stale values of the others.A possible interleaving is: CPU1: load old byte (has_lease=1, on_list=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | IS_OPEN) -> reintroduces cleared bitsTo avoid this class of races, convert these flags to separate boolfields.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43119 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: annotate data-races around hdev->req_status__hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock: hdev->req_status = HCI_REQ_PEND;However, several other functions read or write hdev->req_status withoutholding any lock: - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue) - hci_cmd_sync_complete() reads/writes from HCI event completion - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write - hci_abort_conn() reads in connection abort pathSince __hci_cmd_sync_sk() runs on hdev->req_workqueue whilehci_send_cmd_sync() runs on hdev->workqueue, these are differentworkqueues that can execute concurrently on different CPUs. The plainC accesses constitute a data race.Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accessesto hdev->req_status to prevent potential compiler optimizations thatcould affect correctness (e.g., load fusing in the wait_eventcondition or store reordering).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43209 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:minix: Add required sanity checking to minix_check_superblock()The fs/minix implementation of the minix filesystem does not currentlysupport any other value for s_log_zone_size than 0. This is also theonly value supported in util-linux; see mkfs.minix.c line 511. Inaddition, this patch adds some sanity checking for the other minixsuperblock fields, and moves the minix_blocks_needed() checks for thezmap and imap also to minix_check_super_block().This also closes a related syzbot bug report.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43361 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix transaction abort when snapshotting received subvolumesCurrently a user can trigger a transaction abort by snapshotting apreviously received snapshot a bunch of times until we reach aBTRFS_UUID_KEY_RECEIVED_SUBVOL item overflow (the maximum item size wecan store in a leaf). This is very likely not common in practice, butif it happens, it turns the filesystem into RO mode. The snapshot, sendand set_received_subvol and subvol_setflags (used by receive) don'trequire CAP_SYS_ADMIN, just inode_owner_or_capable(). A malicious usercould use this to turn a filesystem into RO mode and disrupt a system.Reproducer script: $ cat test.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi # Use smallest node size to make the test faster. mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT # Create a subvolume and set it to RO so that it can be used for send. btrfs subvolume create $MNT/sv touch $MNT/sv/foo btrfs property set $MNT/sv ro true # Send and receive the subvolume into snaps/sv. mkdir $MNT/snaps btrfs send $MNT/sv | btrfs receive $MNT/snaps # Now snapshot the received subvolume, which has a received_uuid, a # lot of times to trigger the leaf overflow. total=500 for ((i = 1; i <= $total; i++)); do echo -ne "\rCreating snapshot $i/$total" btrfs subvolume snapshot -r $MNT/snaps/sv $MNT/snaps/sv_$i > /dev/null done echo umount $MNTWhen running the test: $ ./test.sh (...) Create subvolume '/mnt/sdi/sv' At subvol /mnt/sdi/sv At subvol sv Creating snapshot 496/500ERROR: Could not create subvolume: Value too large for defined data type Creating snapshot 497/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 498/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 499/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 500/500ERROR: Could not create subvolume: Read-only file systemAnd in dmesg/syslog: $ dmesg (...) [251067.627338] BTRFS warning (device sdi): insert uuid item failed -75 (0x4628b21c4ac8d898, 0x2598bee2b1515c91) type 252! [251067.629212] ------------[ cut here ]------------ [251067.630033] BTRFS: Transaction aborted (error -75) [251067.630871] WARNING: fs/btrfs/transaction.c:1907 at create_pending_snapshot.cold+0x52/0x465 [btrfs], CPU#10: btrfs/615235 [251067.632851] Modules linked in: btrfs dm_zero (...) [251067.644071] CPU: 10 UID: 0 PID: 615235 Comm: btrfs Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full) [251067.646165] Tainted: [W]=WARN [251067.646733] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [251067.648735] RIP: 0010:create_pending_snapshot.cold+0x55/0x465 [btrfs] [251067.649984] Code: f0 48 0f (...) [251067.653313] RSP: 0018:ffffce644908fae8 EFLAGS: 00010292 [251067.653987] RAX: 00000000ffffff01 RBX: ffff8e5639e63a80 RCX: 00000000ffffffd3 [251067.655042] RDX: ffff8e53faa76b00 RSI: 00000000ffffffb5 RDI: ffffffffc0919750 [251067.656077] RBP: ffffce644908fbd8 R08: 0000000000000000 R09: ffffce644908f820 [251067.657068] R10: ffff8e5adc1fffa8 R11: 0000000000000003 R12: ffff8e53c0431bd0 [251067.658050] R13: ffff8e5414593600 R14: ffff8e55efafd000 R15: 00000000ffffffb5 [251067.659019] FS: 00007f2a4944b3c0(0000) GS:ffff8e5b27dae000(0000) knlGS:0000000000000000 [251067.660115] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [251067.660943] CR2: 00007ffc5aa57898 CR3: 00000005813a2003 CR4: 0000000000370ef0 [251067.661972] Call Trace: [251067.662292] [251067.662653] create_pending_snapshots+0x97/0xc0 [btrfs] [251067.663413] btrfs_commit_transaction+0x26e/0xc00 [btrfs] [251067.664257] ? btrfs_qgroup_convert_reserved_meta+0x35/0x390 [btrfs] [251067.665238] ? _raw_spin_unlock+0x15/0x30 [251067.665837] ? record_root_---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-6357 Severity: Moderate CVSS3 score: 5.8

Description: pip prior to version 26.1 would run self-update check functionality after installing wheel files which required importing well-known Python modules names. These module imports were intentionally deferred to increase startup time of the pip CLI. The patch changes self-update functionality to run before wheels are installed to prevent newly-installed modules from being imported shortly after the installation of a wheel package. Users should still review package contents prior to installation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3 > 0-0 (version in image is 3.6.15-150300.10.118.1).

CVE-2026-53049 Severity: Important CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: add some missing log lockingFunction gfs2_logd() calls the log flushing functions gfs2_ail1_start(),gfs2_ail1_wait(), and gfs2_ail1_empty() without holding sdp->sd_log_flush_lock,but these functions require exclusion against concurrent transactions.To fix that, add a non-locking __gfs2_log_flush() function. Then, ingfs2_logd(), take sdp->sd_log_flush_lock before calling the above mentioned logflushing functions and __gfs2_log_flush().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-21546 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix WRITE_SAME No Data Buffer crashIn newer version of the SBC specs, we have a NDOB bit that indicates thereis no data buffer that gets written out. If this bit is set using commandslike "sg_write_same --ndob" we will crash in target_core_iblock/file'sexecute_write_same handlers when we go to access the se_cmd->t_data_sgbecause its NULL.This patch adds a check for the NDOB bit in the common WRITE SAME codebecause we don't support it. And, it adds a check for zero SG elements ineach handler in case the initiator tries to send a normal WRITE SAME withno data buffer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52593 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()'should check the return value before examining skb data. So convertthe latter to return an appropriate error code and propagate it toreturn from 'wfx_start_ap()' as well. Compile tested only.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38565 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ar5523: enable proper endpoint verificationSyzkaller reports [1] hitting a warning about an endpoint in usenot having an expected type to it.Fix the issue by checking for the existence of all properendpoints with their according types intact.Sadly, this patch has not been tested on real hardware.[1] Syzkaller report:------------[ cut here ]------------usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504...Call Trace: ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56590 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packetThis fixes not checking if skb really contains an ACL header otherwisethe code may attempt to access some uninitilized/invalid memory past thevalid skb->data.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-68785 Severity: Moderate CVSS3 score: 5.7

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31466 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:mm/huge_memory: fix folio isn't locked in softleaf_to_folio()On arm64 server, we found folio that get from migration entry isn't lockedin softleaf_to_folio(). This issue triggers when mTHP splitting andzap_nonpresent_ptes() races, and the root cause is lack of memory barrierin softleaf_to_folio(). The race is as follows: CPU0 CPU1deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pagesIn __split_folio_to_order(), smp_wmb() guarantees page flags of tail pagesare visible before the tail page becomes non-compound. smp_wmb() shouldbe paired with smp_rmb() in softleaf_to_folio(), which is missed. As aresult, if zap_nonpresent_ptes() accesses migration entry that stores tailpfn, softleaf_to_folio() may see the updated compound_head of tail pagebefore page->flags.This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio()because of the race between folio split and zap_nonpresent_ptes()leading to a folio incorrectly undergoing modification without a foliolock being held.This is a BUG_ON() before commit 93976a20345b ("mm: eliminate furtherswapops predicates"), which in merged in v6.19-rc1.To fix it, add missing smp_rmb() if the softleaf entry is migration entryin softleaf_to_folio() and softleaf_to_page().[tujinjiang@huawei.com: update function name and comments]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-42766 Severity: Moderate CVSS3 score: 5.7

Description: Issue summary: A specially crafted password-encrypted CMS messagecan trigger a NULL pointer dereference during CMS decryption.Impact summary: This NULL pointer dereference leads to an application crashand a Denial of Service.The CMS PasswordRecipientInfo.keyDerivationAlgorithm field is defined asOPTIONAL in the ASN.1 specification and may therefore be absent in speciallycrafted inputs. During the password-based CMS decryption the OpenSSLCMS implementation dereferences this field without first checking whether itwas present.An attacker who supplies such a CMS message to an application performingpassword-based CMS decryption can trigger an application crash, leading toa Denial of Service.Applications that process password-encrypted CMS messages may be affected.The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by thisissue, as the affected code is outside the OpenSSL FIPS module boundary.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libopenssl1_1 < 1.1.1l-150400.7.96.2 (version in image is 1.1.1l-150400.7.93.1).

CVE-2026-46086 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: use a stable FDB dst snapshot in RCU readersLocal FDB entries can be rewritten in place by `fdb_delete_local()`, whichupdates `f->dst` to another port or to `NULL` while keeping the entryalive. Several bridge RCU readers inspect `f->dst`, including`br_fdb_fillbuf()` through the `brforward_read()` sysfs path.These readers currently load `f->dst` multiple times and can thereforeobserve inconsistent values across the check and later dereference.In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change`f->dst` after the NULL check and before the `port_no` dereference,leading to a NULL-ptr-deref.Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in eachaffected RCU reader and using that snapshot for the rest of the accesssequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()`with `WRITE_ONCE()` so the readers and writer use matching access patterns.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-5928 Severity: Moderate CVSS3 score: 5.7

Description: Calling the ungetwc function on a FILE stream with wide characters encoded in a character set that has overlaps between its single byte and multi-byte character encodings, in the GNU C Library version 2.43 or earlier, may result in an attempt to read bytes before an allocated buffer, potentially resulting in unintentional disclosure of neighboring data in the heap, or a program crash.A bug in the wide character pushback implementation (_IO_wdefault_pbackfail in libio/wgenops.c) causes ungetwc() to operate on the regular character buffer (fp->_IO_read_ptr) instead of the actual wide-stream read pointer (fp->_wide_data->_IO_read_ptr). The program crash may happen in cases where fp->_IO_read_ptr is not initialized and hence points to NULL. The buffer under-read requires a special situation where the input character encoding is such that there are overlaps between single byte representations and multibyte representations in that encoding, resulting in spurious matches. The spurious match case is not possible in the standard Unicode character sets.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glibc < 2.31-150300.101.1 (version in image is 2.31-150300.98.1).

CVE-2023-4001 Severity: Moderate CVSS3 score: 5.6

Description: An authentication bypass flaw was found in GRUB due to the way that GRUB uses the UUID of a device to search for the configuration file that contains the password hash for the GRUB password protection feature. An attacker capable of attaching an external drive such as a USB stick containing a file system with a duplicate UUID (the same as in the "/boot/" file system) can bypass the GRUB password protection feature on UEFI systems, which enumerate removable drives before non-removable ones. This issue was introduced in a downstream patch in Red Hat's version of grub2 and does not affect the upstream package.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
grub2 > 0-0 (version in image is 2.06-150400.11.72.2).

CVE-2024-35875 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:x86/coco: Require seeding RNG with RDRAND on CoCo systemsThere are few uses of CoCo that don't rely on working cryptography andhence a working RNG. Unfortunately, the CoCo threat model means that theVM host cannot be trusted and may actively work against guests toextract secrets or manipulate computation. Since a malicious host canmodify or observe nearly all inputs to guests, the only remaining sourceof entropy for CoCo guests is RDRAND.If RDRAND is broken -- due to CPU hardware fault -- the RNG as a wholeis meant to gracefully continue on gathering entropy from other sources,but since there aren't other sources on CoCo, this is catastrophic.This is mostly a concern at boot time when initially seeding the RNG, asafter that the consequences of a broken RDRAND are much moretheoretical.So, try at boot to seed the RNG using 256 bits of RDRAND output. If thisfails, panic(). This will also trigger if the system is booted withoutRDRAND, as RDRAND is essential for a safe CoCo boot.Add this deliberately to be "just a CoCo x86 driver feature" and notpart of the RNG itself. Many device drivers and platforms have somedesire to contribute something to the RNG, and add_device_randomness()is specifically meant for this purpose.Any driver can call it with seed data of any quality, or even garbagequality, and it can only possibly make the quality of the RNG better orhave no effect, but can never make it worse.Rather than trying to build something into the core of the RNG, considerthe particular CoCo issue just a CoCo issue, and therefore separate itall out into driver (well, arch/platform) code. [ bp: Massage commit message. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36965 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: mediatek: Make sure IPI buffer fits in L2TCMThe IPI buffer location is read from the firmware that we load to theSystem Companion Processor, and it's not granted that both the SRAM(L2TCM) size that is defined in the devicetree node is large enoughfor that, and while this is especially true for multi-core SCP, it'sstill useful to check on single-core variants as well.Failing to perform this check may make this driver perform R/Woperations out of the L2TCM boundary, resulting (at best) in akernel panic.To fix that, check that the IPI buffer fits, otherwise return afailure and refuse to boot the relevant SCP core (or the SCP atall, if this is single core).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-32414 Severity: Moderate CVSS3 score: 5.6

Description: In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.55.1).

CVE-2025-38422 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devicesMaximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kband 64 Kb respectively. Adjust max size definitions and return correctEEPROM length based on device. Also prevent out-of-bound read/write.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.2.0280-150000.5.89.1).

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23169 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix race in mptcp_pm_nl_flush_addrs_doit()syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id()and/or mptcp_pm_nl_is_backup()Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit()which is not RCU ready.list_splice_init_rcu() can not be called here while holding pernet->lockspinlock.Many thanks to Eulgyu Kim for providing a repro and testing our patches.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31675 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_netem: fix out-of-bounds access in packet corruptionIn netem_enqueue(), the packet corruption logic usesget_random_u32_below(skb_headlen(skb)) to select an index formodifying skb->data. When an AF_PACKET TX_RING sends fully non-linearpackets over an IPIP tunnel, skb_headlen(skb) evaluates to 0.Passing 0 to get_random_u32_below() takes the variable-ceil slow pathwhich returns an unconstrained 32-bit random integer. Using thisunconstrained value as an offset into skb->data results in anout-of-bounds memory access.Fix this by verifying skb_headlen(skb) is non-zero before attemptingto corrupt the linear data area. Fully non-linear packets will silentlybypass the corruption logic.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31676 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: only handle RESPONSE during service challengeOnly process RESPONSE packets while the service connection is still inRXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock beforerunning response verification and security initialization, then use a localsecured flag to decide whether to queue the secured-connection work afterthe state transition. This keeps duplicate or late RESPONSE packets fromre-running the setup path and removes the unlocked post-transition statetest.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-3184 Severity: Moderate CVSS3 score: 5.6

Description: A flaw was found in util-linux. Improper hostname canonicalization in the `login(1)` utility, when invoked with the `-h` option, can modify the supplied remote hostname before setting `PAM_RHOST`. A remote attacker could exploit this by providing a specially crafted hostname, potentially bypassing host-based Pluggable Authentication Modules (PAM) access control rules that rely on fully qualified domain names. This could lead to unauthorized access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libblkid1 > 0-0 (version in image is 2.37.2-150400.8.44.1).

CVE-2026-43333 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: reject direct access to nullable PTR_TO_BUF pointerscheck_mem_access() matches PTR_TO_BUF via base_type() which stripsPTR_MAYBE_NULL, allowing direct dereference without a null check.Map iterator ctx->key and ctx->value are PTR_TO_BUF | PTR_MAYBE_NULL.On stop callbacks these are NULL, causing a kernel NULL dereference.Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching theexisting PTR_TO_BTF_ID pattern.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-46075 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: atmel-sha204a - Fix potential UAF and memory leak in remove pathUnregister the hwrng to prevent new ->read() calls and flush the AtmelI2C workqueue before teardown to prevent a potential UAF if a queuedcallback runs while the device is being removed.Drop the early return to ensure sysfs entries are removed and->hwrng.priv is freed, preventing a memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53176 Severity: Important CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:IB/isert: Reject login PDUs shorter than ISER_HEADERS_LENIn drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done()computes the login request payload length as wc->byte_len minusISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int.A remote iSER initiator can post a login Send work request carryingfewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflowsand login_req_len becomes negative.isert_rx_login_req() then reads that negative length back into a signedint, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because themin() is signed it keeps the negative value; the value is then passed asthe memcpy() length and sign-extended to a multi-gigabyte size_t. Thecopy into the 8192-byte login->req_buf runs far out of bounds andfaults, crashing the target node. The login phase precedes iSCSIauthentication, so no credentials are required to reach this path.Reject any login PDU shorter than ISER_HEADERS_LEN before thesubtraction, mirroring the existing early return on a failed workcompletion, so login_req_len can never go negative. The upper bound wasalready safe: a posted login buffer cannot deliver more thanISER_RX_PAYLOAD_SIZE, so the difference stays at or belowMAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missinglower bound needs to be added.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53186 Severity: Important CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/srp: bound SRP_RSP sense copy by the received lengthsrp_process_rsp() copies sense data from rsp->data + resp_data_len,where resp_data_len is the full 32-bit value supplied by the SRP targetand is never checked against the number of bytes actually received(wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, soat most 96 bytes are copied, but the source offset is not bounded.A malicious or compromised SRP target on the InfiniBand/RoCE fabric thatthe initiator has logged into can return an SRP_RSP withSRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive bufferis allocated at the target-chosen max_ti_iu_len, so the source of thesense copy lands past the bytes actually received; with resp_data_lennear 0xFFFFFFFF it is gigabytes past the buffer and the read faults.Copy the sense data only if it has not been truncated, that is, only ifthe response header, the response data, and the sense region fit withinthe bytes actually received; otherwise drop the sense and log. Thein-tree iSER and NVMe-RDMA receive paths already bound their parse bywc->byte_len; this brings ib_srp into line with them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53215 Severity: Important CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mvpp2: refill RX buffers before XDP or skb useThe RX error path returns the current descriptor buffer to the hardwareBM pool. That is only valid while the driver still owns the buffer.mvpp2_rx_refill() can fail after the current buffer has been handed toXDP or attached to an skb. In those cases mvpp2_run_xdp() may haverecycled, redirected, or queued the page for XDP_TX, and an skb free alsoretires the data buffer. Returning such a buffer to BM lets hardware DMAinto memory that is no longer owned by the RX ring.Refill the BM pool before handing the current buffer to XDP or to theskb. If the allocation fails there, drop the packet and return thestill-owned current buffer to BM, preserving the pool depth. Once therefill succeeds, later local drops retire/free the current buffer insteadof returning it to BM.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-53225 Severity: Important CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: fix uninit-value in __sctp_rcv_asconf_lookup()__sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONFchunk can hold the ADDIP header and a parameter header, then callsaf->from_addr_param(), which reads the full address (16 bytes for IPv6)trusting the parameter's declared length.An unauthenticated peer can send a truncated trailing ASCONF chunk thatdeclares an IPv6 address parameter but stops after the 4-byte parameterheader; reached from the no-association lookup path, from_addr_param() thenreads uninitialized bytes past the parameter.Impact: an unauthenticated SCTP peer makes the receive path read up to 16bytes of uninitialized memory past a truncated ASCONF address parameter.The sibling __sctp_rcv_init_lookup() bounds parameters withsctp_walk_params(); this path open-codes the fetch and omits the bound.Verify the whole address parameter lies within the chunk beforefrom_addr_param() reads it, the same class of fix as commit 51e5ad549c43("net: sctp: fix KMSAN uninit-value in sctp_inq_pop").

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2021-47214 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hugetlb, userfaultfd: fix reservation restore on userfaultfd errorCurrently in the is_continue case in hugetlb_mcopy_atomic_pte(), if webail out using "goto out_release_unlock;" in the cases where idx >=size, or !huge_pte_none(), the code will detect that new_pagecache_page== false, and so call restore_reserve_on_error(). In this case I seerestore_reserve_on_error() delete the reservation, and the followingcall to remove_inode_hugepages() will increment h->resv_hugepagescausing a 100% reproducible leak.We should treat the is_continue case similar to adding a page into thepagecache and set new_pagecache_page to true, to indicate that there isno reservation to restore on the error path, and we need not callrestore_reserve_on_error(). Rename new_pagecache_page topage_in_pagecache to make that clear.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2021-47432 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:lib/generic-radix-tree.c: Don't overflow in peek()When we started spreading new inode numbers throughout most of the 64bit inode space, that triggered some corner case bugs, in particularsome integer overflows related to the radix tree code. Oops.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2021-47512 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: fq_pie: prevent dismantle issueFor some reason, fq_pie_destroy() did not copyworking code from pie_destroy() and other qdiscs,thus causing elusive bug.Before calling del_timer_sync(&q->adapt_timer),we need to ensure timer will not rearm itself.rcu: INFO: rcu_preempt self-detected stall on CPUrcu: 0-....: (4416 ticks this GP) idle=60d/1/0x4000000000000000 softirq=10433/10434 fqs=2579 (t=10501 jiffies g=13085 q=3989)NMI backtrace for cpu 0CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 5.16.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 nmi_cpu_backtrace.cold+0x47/0x144 lib/nmi_backtrace.c:111 nmi_trigger_cpumask_backtrace+0x1b3/0x230 lib/nmi_backtrace.c:62 trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline] rcu_dump_cpu_stacks+0x25e/0x3f0 kernel/rcu/tree_stall.h:343 print_cpu_stall kernel/rcu/tree_stall.h:627 [inline] check_cpu_stall kernel/rcu/tree_stall.h:711 [inline] rcu_pending kernel/rcu/tree.c:3878 [inline] rcu_sched_clock_irq.cold+0x9d/0x746 kernel/rcu/tree.c:2597 update_process_times+0x16d/0x200 kernel/time/timer.c:1785 tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:226 tick_sched_timer+0x1b0/0x2d0 kernel/time/tick-sched.c:1428 __run_hrtimer kernel/time/hrtimer.c:1685 [inline] __hrtimer_run_queues+0x1c0/0xe50 kernel/time/hrtimer.c:1749 hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1086 [inline] __sysvec_apic_timer_interrupt+0x146/0x530 arch/x86/kernel/apic/apic.c:1103 sysvec_apic_timer_interrupt+0x8e/0xc0 arch/x86/kernel/apic/apic.c:1097 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638RIP: 0010:write_comp_data kernel/kcov.c:221 [inline]RIP: 0010:__sanitizer_cov_trace_const_cmp1+0x1d/0x80 kernel/kcov.c:273Code: 54 c8 20 48 89 10 c3 66 0f 1f 44 00 00 53 41 89 fb 41 89 f1 bf 03 00 00 00 65 48 8b 0c 25 40 70 02 00 48 89 ce 4c 8b 54 24 08 4e f7 ff ff 84 c0 74 51 48 8b 81 88 15 00 00 44 8b 81 84 15 00RSP: 0018:ffffc90000d27b28 EFLAGS: 00000246RAX: 0000000000000000 RBX: ffff888064bf1bf0 RCX: ffff888011928000RDX: ffff888011928000 RSI: ffff888011928000 RDI: 0000000000000003RBP: ffff888064bf1c28 R08: 0000000000000000 R09: 0000000000000000R10: ffffffff875d8295 R11: 0000000000000000 R12: 0000000000000000R13: ffff8880783dd300 R14: 0000000000000000 R15: 0000000000000000 pie_calculate_probability+0x405/0x7c0 net/sched/sch_pie.c:418 fq_pie_timer+0x170/0x2a0 net/sched/sch_fq_pie.c:383 call_timer_fn+0x1a5/0x6b0 kernel/time/timer.c:1421 expire_timers kernel/time/timer.c:1466 [inline] __run_timers.part.0+0x675/0xa20 kernel/time/timer.c:1734 __run_timers kernel/time/timer.c:1715 [inline] run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1747 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x2d/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x645/0x9c0 kernel/smpboot.c:164 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2021-47515 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:seg6: fix the iif in the IPv6 socket control blockWhen an IPv4 packet is received, the ip_rcv_core(...) sets the receivinginterface index into the IPv4 socket control block (v5.16-rc4,net/ipv4/ip_input.c line 510): IPCB(skb)->iif = skb->skb_iif;If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRHheader, the seg6_do_srh_encap(...) performs the required encapsulation.In this case, the seg6_do_srh_encap function clears the IPv6 socket controlblock (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clearIP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29).Since the IPv6 socket control block and the IPv4 socket control block sharethe same memory area (skb->cb), the receiving interface index info is lost(IP6CB(skb)->iif is set to zero).As a side effect, that condition triggers a NULL pointer dereference ifcommit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orignetdev") is applied.To fix that issue, we set the IP6CB(skb)->iif with the index of thereceiving interface once again.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2021-47588 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sit: do not call ipip6_dev_free() from sit_init_net()ipip6_dev_free is sit dev->priv_destructor, already calledby register_netdevice() if something goes wrong.Alternative would be to make ipip6_dev_free() robust againstmultiple invocations, but other drivers do not implement thisstrategy.syzbot reported:dst_release underflowWARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173Modules linked in:CPU: 1 PID: 5059 Comm: syz-executor.4 Not tainted 5.16.0-rc5-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c:173Code: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246RAX: d6894a925dd15a00 RBX: 00000000ffffffff RCX: 0000000000040000RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000RBP: 0000000000000000 R08: ffffffff816a1f42 R09: ffffed1017344f2cR10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358R13: 1ffffffff1bfd305 R14: ffffe8ffffcb1358 R15: dffffc0000000000FS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160 ipip6_dev_free net/ipv6/sit.c:1414 [inline] sit_init_net+0x229/0x550 net/ipv6/sit.c:1936 ops_init+0x313/0x430 net/core/net_namespace.c:140 setup_net+0x35b/0x9d0 net/core/net_namespace.c:326 copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470 create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226 ksys_unshare+0x57d/0xb50 kernel/fork.c:3075 __do_sys_unshare kernel/fork.c:3146 [inline] __se_sys_unshare kernel/fork.c:3144 [inline] __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f66c882ce99Code: 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 bc ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000048040200RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2021-47590 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix deadlock in __mptcp_push_pending()__mptcp_push_pending() may call mptcp_flush_join_list() with subflowsocket lock held. If such call hits mptcp_sockopt_sync_all() thensubsequently __mptcp_sockopt_sync() could try to lock the subflowsocket for itself, causing a deadlock.sysrq: Show Blocked Statetask:ss-server state:D stack: 0 pid: 938 ppid: 1 flags:0x00000000Call Trace: __schedule+0x2d6/0x10c0 ? __mod_memcg_state+0x4d/0x70 ? csum_partial+0xd/0x20 ? _raw_spin_lock_irqsave+0x26/0x50 schedule+0x4e/0xc0 __lock_sock+0x69/0x90 ? do_wait_intr_irq+0xa0/0xa0 __lock_sock_fast+0x35/0x50 mptcp_sockopt_sync_all+0x38/0xc0 __mptcp_push_pending+0x105/0x200 mptcp_sendmsg+0x466/0x490 sock_sendmsg+0x57/0x60 __sys_sendto+0xf0/0x160 ? do_wait_intr_irq+0xa0/0xa0 ? fpregs_restore_userregs+0x12/0xd0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f9ba546c2d0RSP: 002b:00007ffdc3b762d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 00007f9ba56c8060 RCX: 00007f9ba546c2d0RDX: 000000000000077a RSI: 0000000000e5e180 RDI: 0000000000000234RBP: 0000000000cc57f0 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9ba56c8060R13: 0000000000b6ba60 R14: 0000000000cc7840 R15: 41d8685b1d7901b8 Fix the issue by using __mptcp_flush_join_list() instead of plainmptcp_flush_join_list() inside __mptcp_push_pending(), as suggested byFlorian. The sockopt sync will be deferred to the workqueue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2021-47591 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: remove tcp ulp setsockopt supportTCP_ULP setsockopt cannot be used for mptcp because its alreadyused internally to plumb subflow (tcp) sockets to the mptcp layer.syzbot managed to trigger a crash for mptcp connections that arein fallback mode:KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]CPU: 1 PID: 1083 Comm: syz-executor.3 Not tainted 5.16.0-rc2-syzkaller #0RIP: 0010:tls_build_proto net/tls/tls_main.c:776 [inline][..] __tcp_set_ulp net/ipv4/tcp_ulp.c:139 [inline] tcp_set_ulp+0x428/0x4c0 net/ipv4/tcp_ulp.c:160 do_tcp_setsockopt+0x455/0x37c0 net/ipv4/tcp.c:3391 mptcp_setsockopt+0x1b47/0x2400 net/mptcp/sockopt.c:638Remove support for TCP_ULP setsockopt.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2021-47593 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: clear 'kern' flag from fallback socketsThe mptcp ULP extension relies on sk->sk_sock_kern being set correctly:It prevents setsockopt(fd, IPPROTO_TCP, TCP_ULP, "mptcp", 6); fromworking for plain tcp sockets (any userspace-exposed socket).But in case of fallback, accept() can return a plain tcp sk.In such case, sk is still tagged as 'kernel' and setsockopt will work.This will crash the kernel, The subflow extension has a NULL ctx->connmptcp socket:BUG: KASAN: null-ptr-deref in subflow_data_ready+0x181/0x2b0Call Trace: tcp_data_ready+0xf8/0x370 [..]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2021-47594 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: never allow the PM to close a listener subflowCurrently, when deleting an endpoint the netlink PM treversesall the local MPTCP sockets, regardless of their status.If an MPTCP listener socket is bound to the IP matching thedelete endpoint, the listener TCP socket will be closed.That is unexpected, the PM should only affect data subflows.Additionally, syzbot was able to trigger a NULL ptr dereferencedue to the above:general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]CPU: 1 PID: 6550 Comm: syz-executor122 Not tainted 5.16.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897Code: 0f 0e 41 be 01 00 00 00 0f 86 c8 00 00 00 89 05 69 cc 0f 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ffRSP: 0018:ffffc90001f2f818 EFLAGS: 00010016RAX: dffffc0000000000 RBX: 0000000000000018 RCX: 0000000000000000RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001R10: 0000000000000000 R11: 000000000000000a R12: 0000000000000000R13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001FS: 00007f177cd3d700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0Call Trace: lock_acquire kernel/locking/lockdep.c:5637 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5602 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162 finish_wait+0xc0/0x270 kernel/sched/wait.c:400 inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [inline] inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497 mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865 inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739 mptcp_stream_accept+0x2e7/0x10e0 net/mptcp/protocol.c:3345 do_accept+0x382/0x510 net/socket.c:1773 __sys_accept4_file+0x7e/0xe0 net/socket.c:1816 __sys_accept4+0xb0/0x100 net/socket.c:1846 __do_sys_accept net/socket.c:1864 [inline] __se_sys_accept net/socket.c:1861 [inline] __x64_sys_accept+0x71/0xb0 net/socket.c:1861 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f177cd8b8e9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 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 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002bRAX: ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003RBP: 00007f177ce13400 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340cR13: 00007f177cde1004 R14: 6d705f706374706d R15: 0000000000022000 Fix the issue explicitly skipping MPTCP socket in TCP_LISTENstatus.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2021-47599 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: use latest_dev in btrfs_show_devnameThe test case btrfs/238 reports the warning below: WARNING: CPU: 3 PID: 481 at fs/btrfs/super.c:2509 btrfs_show_devname+0x104/0x1e8 [btrfs] CPU: 2 PID: 1 Comm: systemd Tainted: G W O 5.14.0-rc1-custom #72 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: btrfs_show_devname+0x108/0x1b4 [btrfs] show_mountinfo+0x234/0x2c4 m_show+0x28/0x34 seq_read_iter+0x12c/0x3c4 vfs_read+0x29c/0x2c8 ksys_read+0x80/0xec __arm64_sys_read+0x28/0x34 invoke_syscall+0x50/0xf8 do_el0_svc+0x88/0x138 el0_svc+0x2c/0x8c el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x198/0x19cReason:While btrfs_prepare_sprout() moves the fs_devices::devices intofs_devices::seed_list, the btrfs_show_devname() searches for the devicesand found none, leading to the warning as in above.Fix:latest_dev is updated according to the changes to the device list.That means we could use the latest_dev->name to show the device name in/proc/self/mounts, the pointer will be always valid as it's assignedbefore the device is deleted from the list in remove or replace.The RCU protection is sufficient as the device structure is freed aftersynchronization.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2021-47606 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: netlink: af_netlink: Prevent empty skb by adding a check on len.Adding a check on len parameter to avoid empty skb. This prevents adivision error in netem_enqueue function which is caused when skb->len=0and skb->data_len=0 in the randomized corruption step as shown below.skb->data[prandom_u32() % skb_headlen(skb)] ^= 1<<(prandom_u32() % 8);Crash Report:[ 343.170349] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family0 port 6081 - 0[ 343.216110] netem: version 1.3[ 343.235841] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI[ 343.236680] CPU: 3 PID: 4288 Comm: reproducer Not tainted 5.16.0-rc1+[ 343.237569] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS 1.11.0-2.el7 04/01/2014[ 343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem][ 343.239499] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ffff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f74 f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03[ 343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246[ 343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX:0000000000000000[ 343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI:ffff88800f8eda40[ 343.244474] RBP: ffff88800bcd7458 R08: 0000000000000000 R09:ffffffff94fb8445[ 343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12:0000000000000000[ 343.246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15:0000000000000020[ 343.247291] FS: 00007fdde2bd7700(0000) GS:ffff888109780000(0000)knlGS:0000000000000000[ 343.248350] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4:00000000000006e0[ 343.250076] Call Trace:[ 343.250423] [ 343.250713] ? memcpy+0x4d/0x60[ 343.251162] ? netem_init+0xa0/0xa0 [sch_netem][ 343.251795] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.252443] netem_enqueue+0xe28/0x33c0 [sch_netem][ 343.253102] ? stack_trace_save+0x87/0xb0[ 343.253655] ? filter_irq_stacks+0xb0/0xb0[ 343.254220] ? netem_init+0xa0/0xa0 [sch_netem][ 343.254837] ? __kasan_check_write+0x14/0x20[ 343.255418] ? _raw_spin_lock+0x88/0xd6[ 343.255953] dev_qdisc_enqueue+0x50/0x180[ 343.256508] __dev_queue_xmit+0x1a7e/0x3090[ 343.257083] ? netdev_core_pick_tx+0x300/0x300[ 343.257690] ? check_kcov_mode+0x10/0x40[ 343.258219] ? _raw_spin_unlock_irqrestore+0x29/0x40[ 343.258899] ? __kasan_init_slab_obj+0x24/0x30[ 343.259529] ? setup_object.isra.71+0x23/0x90[ 343.260121] ? new_slab+0x26e/0x4b0[ 343.260609] ? kasan_poison+0x3a/0x50[ 343.261118] ? kasan_unpoison+0x28/0x50[ 343.261637] ? __kasan_slab_alloc+0x71/0x90[ 343.262214] ? memcpy+0x4d/0x60[ 343.262674] ? write_comp_data+0x2f/0x90[ 343.263209] ? __kasan_check_write+0x14/0x20[ 343.263802] ? __skb_clone+0x5d6/0x840[ 343.264329] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.264958] dev_queue_xmit+0x1c/0x20[ 343.265470] netlink_deliver_tap+0x652/0x9c0[ 343.266067] netlink_unicast+0x5a0/0x7f0[ 343.266608] ? netlink_attachskb+0x860/0x860[ 343.267183] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.267820] ? write_comp_data+0x2f/0x90[ 343.268367] netlink_sendmsg+0x922/0xe80[ 343.268899] ? netlink_unicast+0x7f0/0x7f0[ 343.269472] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.270099] ? write_comp_data+0x2f/0x90[ 343.270644] ? netlink_unicast+0x7f0/0x7f0[ 343.271210] sock_sendmsg+0x155/0x190[ 343.271721] ____sys_sendmsg+0x75f/0x8f0[ 343.272262] ? kernel_sendmsg+0x60/0x60[ 343.272788] ? write_comp_data+0x2f/0x90[ 343.273332] ? write_comp_data+0x2f/0x90[ 343.273869] ___sys_sendmsg+0x10f/0x190[ 343.274405] ? sendmsg_copy_msghdr+0x80/0x80[ 343.274984] ? slab_post_alloc_hook+0x70/0x230[ 343.275597] ? futex_wait_setup+0x240/0x240[ 343.276175] ? security_file_alloc+0x3e/0x170[ 343.276779] ? write_comp_d---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48639 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: fix possible refcount leak in tc_new_tfilter()tfilter_put need to be called to put the refount got by tp->ops->get toavoid possible refcount leak when chain->tmplt_ops != NULL andchain->tmplt_ops != tp->ops.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48640 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: fix NULL deref in bond_rr_gen_slave_idFix a NULL dereference of the struct bonding.rr_tx_counter member becauseif a bond is initially created with an initial mode != zero (Round Robin)the memory required for the counter is never created and when the mode ischanged there is never any attempt to verify the memory is allocated uponswitching modes.This causes the following Oops on an aarch64 machine: [ 334.686773] Unable to handle kernel paging request at virtual address ffff2c91ac905000 [ 334.694703] Mem abort info: [ 334.697486] ESR = 0x0000000096000004 [ 334.701234] EC = 0x25: DABT (current EL), IL = 32 bits [ 334.706536] SET = 0, FnV = 0 [ 334.709579] EA = 0, S1PTW = 0 [ 334.712719] FSC = 0x04: level 0 translation fault [ 334.717586] Data abort info: [ 334.720454] ISV = 0, ISS = 0x00000004 [ 334.724288] CM = 0, WnR = 0 [ 334.727244] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000008044d662000 [ 334.733944] [ffff2c91ac905000] pgd=0000000000000000, p4d=0000000000000000 [ 334.740734] Internal error: Oops: 96000004 [#1] SMP [ 334.745602] Modules linked in: bonding tls veth rfkill sunrpc arm_spe_pmu vfat fat acpi_ipmi ipmi_ssif ixgbe igb i40e mdio ipmi_devintf ipmi_msghandler arm_cmn arm_dsu_pmu cppc_cpufreq acpi_tad fuse zram crct10dif_ce ast ghash_ce sbsa_gwdt nvme drm_vram_helper drm_ttm_helper nvme_core ttm xgene_hwmon [ 334.772217] CPU: 7 PID: 2214 Comm: ping Not tainted 6.0.0-rc4-00133-g64ae13ed4784 #4 [ 334.779950] Hardware name: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 [ 334.789244] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 334.796196] pc : bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.801691] lr : bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.807962] sp : ffff8000221733e0 [ 334.811265] x29: ffff8000221733e0 x28: ffffdbac8572d198 x27: ffff80002217357c [ 334.818392] x26: 000000000000002a x25: ffffdbacb33ee000 x24: ffff07ff980fa000 [ 334.825519] x23: ffffdbacb2e398ba x22: ffff07ff98102000 x21: ffff07ff981029c0 [ 334.832646] x20: 0000000000000001 x19: ffff07ff981029c0 x18: 0000000000000014 [ 334.839773] x17: 0000000000000000 x16: ffffdbacb1004364 x15: 0000aaaabe2f5a62 [ 334.846899] x14: ffff07ff8e55d968 x13: ffff07ff8e55db30 x12: 0000000000000000 [ 334.854026] x11: ffffdbacb21532e8 x10: 0000000000000001 x9 : ffffdbac857178ec [ 334.861153] x8 : ffff07ff9f6e5a28 x7 : 0000000000000000 x6 : 000000007c2b3742 [ 334.868279] x5 : ffff2c91ac905000 x4 : ffff2c91ac905000 x3 : ffff07ff9f554400 [ 334.875406] x2 : ffff2c91ac905000 x1 : 0000000000000001 x0 : ffff07ff981029c0 [ 334.882532] Call trace: [ 334.884967] bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.890109] bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.896033] __bond_start_xmit+0x128/0x3a0 [bonding] [ 334.901001] bond_start_xmit+0x54/0xb0 [bonding] [ 334.905622] dev_hard_start_xmit+0xb4/0x220 [ 334.909798] __dev_queue_xmit+0x1a0/0x720 [ 334.913799] arp_xmit+0x3c/0xbc [ 334.916932] arp_send_dst+0x98/0xd0 [ 334.920410] arp_solicit+0xe8/0x230 [ 334.923888] neigh_probe+0x60/0xb0 [ 334.927279] __neigh_event_send+0x3b0/0x470 [ 334.931453] neigh_resolve_output+0x70/0x90 [ 334.935626] ip_finish_output2+0x158/0x514 [ 334.939714] __ip_finish_output+0xac/0x1a4 [ 334.943800] ip_finish_output+0x40/0xfc [ 334.947626] ip_output+0xf8/0x1a4 [ 334.950931] ip_send_skb+0x5c/0x100 [ 334.954410] ip_push_pending_frames+0x3c/0x60 [ 334.958758] raw_sendmsg+0x458/0x6d0 [ 334.962325] inet_sendmsg+0x50/0x80 [ 334.965805] sock_sendmsg+0x60/0x6c [ 334.969286] __sys_sendto+0xc8/0x134 [ 334.972853] __arm64_sys_sendto+0x34/0x4c---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48644 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: taprio: avoid disabling offload when it was never enabledIn an incredibly strange API design decision, qdisc->destroy() getscalled even if qdisc->init() never succeeded, not exclusively sincecommit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"),but apparently also earlier (in the case of qdisc_create_dflt()).The taprio qdisc does not fully acknowledge this when it attempts fulloffload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID intaprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGSparsed from netlink (in taprio_change(), tail called from taprio_init()).But in taprio_destroy(), we call taprio_disable_offload(), and thisdetermines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags).But looking at the implementation of FULL_OFFLOAD_IS_ENABLED()(a bitwise check of bit 1 in q->flags), it is invalid to call this macroon q->flags when it contains TAPRIO_FLAGS_INVALID, because that is setto U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true onan invalid set of flags.As a result, it is possible to crash the kernel if user space forces anerror between setting q->flags = TAPRIO_FLAGS_INVALID, and the callingof taprio_enable_offload(). This is because drivers do not expect theoffload to be disabled when it was never enabled.The error that we force here is to attach taprio as a non-root qdisc,but instead as child of an mqprio root qdisc:$ tc qdisc add dev swp0 root handle 1: \ mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0$ tc qdisc replace dev swp0 parent 1:1 \ taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCK_TAIUnable to handle kernel paging request at virtual address fffffffffffffff8[fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 96000004 [#1] PREEMPT SMPCall trace: taprio_dump+0x27c/0x310 vsc9959_port_setup_tc+0x1f4/0x460 felix_port_setup_tc+0x24/0x3c dsa_slave_setup_tc+0x54/0x27c taprio_disable_offload.isra.0+0x58/0xe0 taprio_destroy+0x80/0x104 qdisc_create+0x240/0x470 tc_modify_qdisc+0x1fc/0x6b0 rtnetlink_rcv_msg+0x12c/0x390 netlink_rcv_skb+0x5c/0x130 rtnetlink_rcv+0x1c/0x2cFix this by keeping track of the operations we made, and undo theoffload only if we actually did it.I've added "bool offloaded" inside a 4 byte hole between "int clockid"and "atomic64_t picos_per_byte". Now the first cache line looks likebelow:$ pahole -C taprio_sched net/sched/sch_taprio.ostruct taprio_sched { struct Qdisc * * qdiscs; /* 0 8 */ struct Qdisc * root; /* 8 8 */ u32 flags; /* 16 4 */ enum tk_offsets tk_offset; /* 20 4 */ int clockid; /* 24 4 */ bool offloaded; /* 28 1 */ /* XXX 3 bytes hole, try to pack */ atomic64_t picos_per_byte; /* 32 0 */ /* XXX 8 bytes hole, try to pack */ spinlock_t current_entry_lock; /* 40 0 */ /* XXX 8 bytes hole, try to pack */ struct sched_entry * current_entry; /* 48 8 */ struct sched_gate_list * oper_sched; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48646 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sfc/siena: fix null pointer dereference in efx_hard_start_xmitLike in previous patch for sfc, prevent potential (but unlikely) NULLpointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48658 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context.Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations__free_slab() invocations out of IRQ context") moved all flush_cpu_slab()invocations to the global workqueue to avoid a problem relatedwith deactivate_slab()/__free_slab() being called from an IRQ contexton PREEMPT_RT kernels.When the flush_all_cpu_locked() function is called from a task contextit may happen that a workqueue with WQ_MEM_RECLAIM bit set ends upflushing the global workqueue, this will cause a dependency issue. workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core] is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637 check_flush_dependency+0x10a/0x120 Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core] RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace: __flush_work.isra.0+0xbf/0x220 ? __queue_work+0x1dc/0x420 flush_all_cpus_locked+0xfb/0x120 __kmem_cache_shutdown+0x2b/0x320 kmem_cache_destroy+0x49/0x100 bioset_exit+0x143/0x190 blk_release_queue+0xb9/0x100 kobject_cleanup+0x37/0x130 nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc] nvme_free_ctrl+0x1ac/0x2b0 [nvme_core]Fix this bug by creating a workqueue for the flush operation withthe WQ_MEM_RECLAIM bit set.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48666 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Fix a use-after-freeThere are two .exit_cmd_priv implementations. Both implementations useresources associated with the SCSI host. Make sure that these resources arestill available when .exit_cmd_priv is called by waiting insidescsi_remove_host() until the tag set has been freed.This commit fixes the following use-after-free:==================================================================BUG: KASAN: use-after-free in srp_exit_cmd_priv+0x27/0xd0 [ib_srp]Read of size 8 at addr ffff888100337000 by task multipathd/16727Call Trace: dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db kasan_report+0xab/0x120 srp_exit_cmd_priv+0x27/0xd0 [ib_srp] scsi_mq_exit_request+0x4d/0x70 blk_mq_free_rqs+0x143/0x410 __blk_mq_free_map_and_rqs+0x6e/0x100 blk_mq_free_tag_set+0x2b/0x160 scsi_host_dev_release+0xf3/0x1a0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_device_dev_release_usercontext+0x4c1/0x4e0 execute_in_process_context+0x23/0x90 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_disk_release+0x3f/0x50 device_release+0x54/0xe0 kobject_put+0xa5/0x120 disk_release+0x17f/0x1b0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 dm_put_table_device+0xa3/0x160 [dm_mod] dm_put_device+0xd0/0x140 [dm_mod] free_priority_group+0xd8/0x110 [dm_multipath] free_multipath+0x94/0xe0 [dm_multipath] dm_table_destroy+0xa2/0x1e0 [dm_mod] __dm_destroy+0x196/0x350 [dm_mod] dev_remove+0x10c/0x160 [dm_mod] ctl_ioctl+0x2c2/0x590 [dm_mod] dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48669 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: Fix potential memleak in papr_get_attr()`buf` is allocated in papr_get_attr(), and krealloc() of `buf`could fail. We need to free the original `buf` in the case of failure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48716 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: wcd938x: fix incorrect used of portidMixer controls have the channel id in mixer->reg, which is not sameas port id. port id should be derived from chan_info array.So fix this. Without this, its possible that we could corruptstruct wcd938x_sdw_priv by accessing port_map array out of rangewith channel id instead of port id.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48742 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink()While looking at one unrelated syzbot bug, I found the replay logicin __rtnl_newlink() to potentially trigger use-after-free.It is better to clear master_dev and m_ops inside the loop,in case we have to replay it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48755 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06Johan reported the below crash with test_bpf on ppc64 e5500: test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1 Oops: Exception in kernel mode, sig: 4 [#1] BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500 Modules linked in: test_bpf(+) CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1 NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18 REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e008a-dirty) MSR: 0000000080089000 CR: 88002822 XER: 20000000 IRQMASK: 0 <...> NIP [8000000000061c3c] 0x8000000000061c3c LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf] Call Trace: .__run_one+0x60/0x17c [test_bpf] (unreliable) .test_bpf_init+0x6a8/0xdc8 [test_bpf] .do_one_initcall+0x6c/0x28c .do_init_module+0x68/0x28c .load_module+0x2460/0x2abc .__do_sys_init_module+0x120/0x18c .system_call_exception+0x110/0x1b8 system_call_common+0xf0/0x210 --- interrupt: c00 at 0x101d0acc <...> ---[ end trace 47b2bf19090bb3d0 ]--- Illegal instructionThe illegal instruction turned out to be 'ldbrx' emitted forBPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use ofthe same and implement an alternative approach for older processors.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48757 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix information leakage in /proc/net/ptypeIn one net namespace, after creating a packet socket without bindingit to a device, users in other net namespaces can observe the new`packet_type` added by this packet socket by reading `/proc/net/ptype`file. This is minor information leakage as packet socket isnamespace aware.Add a net pointer in `packet_type` to keep the net namespace ofof corresponding packet socket. In `ptype_seq_show`, this net pointermust be checked when it is not NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48766 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU.Mirrors the logic for dcn30. Cue lots of WARNs and somekernel panics without this fix.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48770 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack()task_pt_regs() can return NULL on powerpc for kernel threads. This isthen used in __bpf_get_stack() to check for user mode, resulting in akernel oops. Guard against this by checking return value oftask_pt_regs() before trying to obtain the call chain.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48772 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: lgdt3306a: Add a check against null-pointer-defThe driver should check whether the client provides the platform_data.The following log reveals it:[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40[ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414[ 29.612820] Call Trace:[ 29.613030] [ 29.613201] dump_stack_lvl+0x56/0x6f[ 29.613496] ? kmemdup+0x30/0x40[ 29.613754] print_report.cold+0x494/0x6b7[ 29.614082] ? kmemdup+0x30/0x40[ 29.614340] kasan_report+0x8a/0x190[ 29.614628] ? kmemdup+0x30/0x40[ 29.614888] kasan_check_range+0x14d/0x1d0[ 29.615213] memcpy+0x20/0x60[ 29.615454] kmemdup+0x30/0x40[ 29.615700] lgdt3306a_probe+0x52/0x310[ 29.616339] i2c_device_probe+0x951/0xa90

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48809 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix a memleak when uncloning an skb dst and its metadataWhen uncloning an skb dst and its associated metadata, a newdst+metadata is allocated and later replaces the old one in the skb.This is helpful to have a non-shared dst+metadata attached to a specificskb.The issue is the uncloned dst+metadata is initialized with a refcount of1, which is increased to 2 before attaching it to the skb. Whentun_dst_unclone returns, the dst+metadata is only referenced from asingle place (the skb) while its refcount is 2. Its refcount will neverdrop to 0 (when the skb is consumed), leading to a memory leak.Fix this by removing the call to dst_hold in tun_dst_unclone, as thedst+metadata refcount is already 1.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48810 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() on failure pathip[6]mr_free_table() can only be called under RTNL lock.RTNL: assertion failed at net/core/dev.c (10367)WARNING: CPU: 1 PID: 5890 at net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367Modules linked in:CPU: 1 PID: 5890 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller-11627-g422ee58dc0ef #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367Code: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 6d b1 51 06 01 e8 8c 90 d8 01 <0f> 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 eeRSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfeceRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: ffffffff815f3d6e R11: 0000000000000000 R12: 00000000fffffff4R13: dffffc0000000000 R14: ffffc900046ff750 R15: ffff88807b7dc000FS: 00007f4ab736e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509 ip6mr_free_table net/ipv6/ip6mr.c:389 [inline] ip6mr_rules_init net/ipv6/ip6mr.c:246 [inline] ip6mr_net_init net/ipv6/ip6mr.c:1306 [inline] ip6mr_net_init+0x3f0/0x4e0 net/ipv6/ip6mr.c:1298 ops_init+0xaf/0x470 net/core/net_namespace.c:140 setup_net+0x54f/0xbb0 net/core/net_namespace.c:331 copy_net_ns+0x318/0x760 net/core/net_namespace.c:475 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110 copy_namespaces+0x391/0x450 kernel/nsproxy.c:178 copy_process+0x2e0c/0x7300 kernel/fork.c:2167 kernel_clone+0xe7/0xab0 kernel/fork.c:2555 __do_sys_clone+0xc8/0x110 kernel/fork.c:2672 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f4ab89f9059Code: Unable to access opcode bytes at RIP 0x7f4ab89f902f.RSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: 0000000000000038RAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059RDX: 0000000020000280 RSI: 0000000020000270 RDI: 0000000040200000RBP: 00007f4ab8a5308d R08: 0000000020000300 R09: 0000000020000300R10: 00000000200002c0 R11: 0000000000000206 R12: 0000000000000000R13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: 0000000000022000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: hdmi: Unregister codec device on unbindOn bind we will register the HDMI codec device but we don't unregisterit on unbind, leading to a device leakage. Unregister our device atunbind.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: fix kernel-infoleak for SCTP socketssyzbot reported a kernel infoleak [1] of 4 bytes.After analysis, it turned out r->idiag_expires is not initializedif inet_sctp_diag_fill() calls inet_diag_msg_common_fill()Make sure to clear idiag_timer/idiag_retrans/idiag_expiresand let inet_diag_msg_sctpasoc_fill() fill them again if needed.[1]BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:154 [inline] _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 copy_to_iter include/linux/uio.h:162 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline] netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] __sys_recvfrom+0x795/0xa10 net/socket.c:2097 __do_sys_recvfrom net/socket.c:2115 [inline] __se_sys_recvfrom net/socket.c:2111 [inline] __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeUninit was created at: slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3247 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1158 [inline] netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248 __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] sock_write_iter+0x594/0x690 net/socket.c:1061 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeBytes 68-71 of 2508 are uninitializedMemory access of size 2508 starts at ffff888114f9b000Data copied to user address 00007f7fe09ff2e0CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48865 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix kernel panic when enabling bearerWhen enabling a bearer on a node, a kernel panic is observed:[ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]...[ 4.520030] Call Trace:[ 4.520689] [ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc][ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc][ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc][ 4.525292] tipc_rcv+0x5da/0x730 [tipc][ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0[ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc][ 4.528737] __netif_receive_skb_list_core+0x20b/0x260[ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0[ 4.531450] ? dev_gro_receive+0x4c2/0x680[ 4.532512] napi_complete_done+0x6f/0x180[ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net]...The node in question is receiving activate messages in anotherthread after changing bearer status to allow message sending/receiving in current thread: thread 1 | thread 2 -------- | -------- |tipc_enable_bearer() | test_and_set_bit_lock() | tipc_bearer_xmit_skb() | | tipc_l2_rcv_msg() | tipc_rcv() | __tipc_node_link_up() | tipc_link_build_state_msg() | tipc_link_build_proto_msg() | tipc_mon_prep() | { | ... | // null-pointer dereference | u16 gen = mon->dom_gen; | ... | } // Not being executed yet | tipc_mon_create() | { | ... | // allocate | mon = kzalloc(); | ... | } |Monitoring pointer in thread 2 is dereferenced before monitoring datais allocated in thread 1. This causes kernel panic.This commit fixes it by allocating the monitoring data before enablingthe bearer to receive messages.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48901 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not start relocation until in progress drops are doneWe hit a bug with a recovering relocation on mount for one of our filesystems in production. I reproduced this locally by injecting errorsinto snapshot delete with balance running at the same time. Thispresented as an error while looking up an extent item WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680 CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8 RIP: 0010:lookup_inline_extent_backref+0x647/0x680 RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000 RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001 R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000 R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000 FS: 0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0 Call Trace: insert_inline_extent_backref+0x46/0xd0 __btrfs_inc_extent_ref.isra.0+0x5f/0x200 ? btrfs_merge_delayed_refs+0x164/0x190 __btrfs_run_delayed_refs+0x561/0xfa0 ? btrfs_search_slot+0x7b4/0xb30 ? btrfs_update_root+0x1a9/0x2c0 btrfs_run_delayed_refs+0x73/0x1f0 ? btrfs_update_root+0x1a9/0x2c0 btrfs_commit_transaction+0x50/0xa50 ? btrfs_update_reloc_root+0x122/0x220 prepare_to_merge+0x29f/0x320 relocate_block_group+0x2b8/0x550 btrfs_relocate_block_group+0x1a6/0x350 btrfs_relocate_chunk+0x27/0xe0 btrfs_balance+0x777/0xe60 balance_kthread+0x35/0x50 ? btrfs_balance+0xe60/0xe60 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 Normally snapshot deletion and relocation are excluded from running atthe same time by the fs_info->cleaner_mutex. However if we had apending balance waiting to get the ->cleaner_mutex, and a snapshotdeletion was running, and then the box crashed, we would come up in astate where we have a half deleted snapshot.Again, in the normal case the snapshot deletion needs to complete beforerelocation can start, but in this case relocation could very well startbefore the snapshot deletion completes, as we simply add the root to thedead roots list and wait for the next time the cleaner runs to clean upthe snapshot.Fix this by setting a bit on the fs_info if we have any DEAD_ROOT's thathad a pending drop_progress key. If they do then we know we were in themiddle of the drop operation and set a flag on the fs_info. Thenbalance can wait until this flag is cleared to start up again.If there are DEAD_ROOT's that don't have a drop_progress set then we'resafe to start balance right away as we'll be properly protected by thecleaner_mutex.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48902 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not WARN_ON() if we have PageError setWhenever we do any extent buffer operations we callassert_eb_page_uptodate() to complain loudly if we're operating on annon-uptodate page. Our overnight tests caught this warning earlier thisweek WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Call Trace: extent_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree+0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_release+0x1f0/0x2d0 ? finish_task_switch.isra.0+0xf9/0x3a0 process_one_work+0x26d/0x580 ? process_one_work+0x580/0x580 worker_thread+0x55/0x3b0 ? process_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30This was partially fixed by c2e39305299f01 ("btrfs: clear extent bufferuptodate when we fail to write it"), however all that fix did was keepus from finding extent buffers after a failed writeout. It didn't keepus from continuing to use a buffer that we already had found.In this case we're searching the commit root to cache the block group,so we can start committing the transaction and switch the commit rootand then start writing. After the switch we can look up an extentbuffer that hasn't been written yet and start processing that blockgroup. Then we fail to write that block out and clear Uptodate on thepage, and then we start spewing these errors.Normally we're protected by the tree lock to a certain degree here. Ifwe read a block we have that block read locked, and we block the writerfrom locking the block before we submit it for the write. However thisisn't necessarily fool proof because the read could happen before we dothe submit_bio and after we locked and unlocked the extent buffer.Also in this particular case we have path->skip_locking set, so thatwon't save us here. We'll simply get a block that was valid when weread it, but became invalid while we were using it.What we really want is to catch the case where we've "read" a block butit's not marked Uptodate. On read we ClearPageError(), so if we're!Uptodate and !Error we know we didn't do the right thing for readingthe page.Fix this by checking !Uptodate && !Error, this way we will not complainif our buffer gets invalidated while we're using it, and we'll maintainthe spirit of the check which is to make sure we have a fully in-cacheblock while we're messing with it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48920 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: get rid of warning on transaction commit when using flushoncommitWhen using the flushoncommit mount option, during almost every transactioncommit we trigger a warning from __writeback_inodes_sb_nr(): $ cat fs/fs-writeback.c: (...) static void __writeback_inodes_sb_nr(struct super_block *sb, ... { (...) WARN_ON(!rwsem_is_locked(&sb->s_umount)); (...) } (...)The trace produced in dmesg looks like the following: [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3 [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186 [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3 [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...) [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246 [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000 [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50 [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000 [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488 [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460 [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000 [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0 [947.571072] Call Trace: [947.572354] [947.573266] btrfs_commit_transaction+0x1f1/0x998 [947.576785] ? start_transaction+0x3ab/0x44e [947.579867] ? schedule_timeout+0x8a/0xdd [947.582716] transaction_kthread+0xe9/0x156 [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407 [947.590104] kthread+0x131/0x139 [947.592168] ? set_kthread_struct+0x32/0x32 [947.595174] ret_from_fork+0x22/0x30 [947.597561] [947.598553] ---[ end trace 644721052755541c ]---This is because we started using writeback_inodes_sb() to flush delallocwhen committing a transaction (when using -o flushoncommit), in order toavoid deadlocks with filesystem freeze operations. This change was madeby commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_rootsin flushoncommit"). After that change we started producing that warning,and every now and then a user reports this since the warning happens toooften, it spams dmesg/syslog, and a user is unsure if this reflects anyproblem that might compromise the filesystem's reliability.We can not just lock the sb->s_umount semaphore before callingwriteback_inodes_sb(), because that would at least deadlock withfilesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()is called while we are holding that semaphore in write mode, and that cantrigger a transaction commit, resulting in a deadlock. It would alsotrigger the same type of deadlock in the unmount path. Possibly, it couldalso introduce some other locking dependencies that lockdep would report.To fix this call try_to_writeback_inodes_sb() instead ofwriteback_inodes_sb(), because that will try to read lock sb->s_umountand then will only call writeback_inodes_sb() if it was able to lock it.This is fine because the cases where it can't read lock sb->s_umountare during a filesystem unmount or during a filesystem freeze - in thosecases sb->s_umount is write locked and sync_filesystem() is called, whichcalls writeback_inodes_sb(). In other words, in all cases where we can'ttake a read lock on sb->s_umount, writeback is already being triggeredelsewhere.An alternative would be to call btrfs_start_delalloc_roots() with anumber of pages different from LONG_MAX, for example matching the numberof delalloc bytes we currently have, in ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:riscv: fix oops caused by irqsoff latency tracerThe trace_hardirqs_{on,off}() require the caller to setup frame pointerproperly. This because these two functions use macro 'CALLER_ADDR1' (aka.__builtin_return_address(1)) to acquire caller info. If the $fp is usedfor other purpose, the code generated this macro (as below) could triggermemory access fault. 0xffffffff8011510e <+80>: ld a1,-16(s0) 0xffffffff80115112 <+84>: ld s2,-8(a1) # <-- paging fault hereThe oops message during booting if compiled with 'irqoff' tracer enabled:[ 0.039615][ T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8[ 0.041925][ T0] Oops [#1][ 0.042063][ T0] Modules linked in:[ 0.042864][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29[ 0.043568][ T0] Hardware name: riscv-virtio,qemu (DT)[ 0.044343][ T0] epc : trace_hardirqs_on+0x56/0xe2[ 0.044601][ T0] ra : restore_all+0x12/0x6e[ 0.044721][ T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0[ 0.044801][ T0] gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020[ 0.044882][ T0] t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0[ 0.044967][ T0] s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100[ 0.045046][ T0] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000[ 0.045124][ T0] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000054494d45[ 0.045210][ T0] s2 : ffffffff80003b94 s3 : ffffffff81a8f1b0 s4 : ffffffff80e27b50[ 0.045289][ T0] s5 : ffffffff81414880 s6 : ffffffff8160fa00 s7 : 00000000800120e8[ 0.045389][ T0] s8 : 0000000080013100 s9 : 000000000000007f s10: 0000000000000000[ 0.045474][ T0] s11: 0000000000000000 t3 : 7fffffffffffffff t4 : 0000000000000000[ 0.045548][ T0] t5 : 0000000000000000 t6 : ffffffff814aa368[ 0.045620][ T0] status: 0000000200000100 badaddr: 00000000000000f8 cause: 000000000000000d[ 0.046402][ T0] [] restore_all+0x12/0x6eThis because the $fp(aka. $s0) register is not used as frame pointer in theassembly entry code. resume_kernel: REG_L s0, TASK_TI_PREEMPT_COUNT(tp) bnez s0, restore_all REG_L s0, TASK_TI_FLAGS(tp) andi s0, s0, _TIF_NEED_RESCHED beqz s0, restore_all call preempt_schedule_irq j restore_allTo fix above issue, here we add one extra level wrapper for functiontrace_hardirqs_{on,off}() so they can be safely called by low level entrycode.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48933 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix memory leak during stateful obj updatestateful objects can be updated from the control plane.The transaction logic allocates a temporary object for this purpose.The ->init function was called for this object, so plain kfree() leaksresources. We must call ->destroy function of the object.nft_obj_destroy does this, but it also decrements the module refcount,but the update path doesn't increment it.To avoid special-casing the update object release, do module_get forthe update case too and release it via nft_obj_destroy().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48952 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: mt7621: Add sentinel to quirks tableCurrent driver is missing a sentinel in the struct soc_device_attributearray, which causes an oops when assessed by thesoc_device_match(mt7621_pcie_quirks_match) call.This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attrwas fixed to register the SOC as a device, in:commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early")Fix it by adding the required sentinel.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-48982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix crash when replugging CSR fake controllersIt seems fake CSR 5.0 clones can cause the suspend notifier to beregistered twice causing the following kernel panic:[ 71.986122] Call Trace:[ 71.986124] [ 71.986125] blocking_notifier_chain_register+0x33/0x60[ 71.986130] hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da][ 71.986154] btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477][ 71.986159] ? __pm_runtime_set_status+0x1a9/0x300[ 71.986162] ? ktime_get_mono_fast_ns+0x3e/0x90[ 71.986167] usb_probe_interface+0xe3/0x2b0[ 71.986171] really_probe+0xdb/0x380[ 71.986174] ? pm_runtime_barrier+0x54/0x90[ 71.986177] __driver_probe_device+0x78/0x170[ 71.986180] driver_probe_device+0x1f/0x90[ 71.986183] __device_attach_driver+0x89/0x110[ 71.986186] ? driver_allows_async_probing+0x70/0x70[ 71.986189] bus_for_each_drv+0x8c/0xe0[ 71.986192] __device_attach+0xb2/0x1e0[ 71.986195] bus_probe_device+0x92/0xb0[ 71.986198] device_add+0x422/0x9a0[ 71.986201] ? sysfs_merge_group+0xd4/0x110[ 71.986205] usb_set_configuration+0x57a/0x820[ 71.986208] usb_generic_driver_probe+0x4f/0x70[ 71.986211] usb_probe_device+0x3a/0x110[ 71.986213] really_probe+0xdb/0x380[ 71.986216] ? pm_runtime_barrier+0x54/0x90[ 71.986219] __driver_probe_device+0x78/0x170[ 71.986221] driver_probe_device+0x1f/0x90[ 71.986224] __device_attach_driver+0x89/0x110[ 71.986227] ? driver_allows_async_probing+0x70/0x70[ 71.986230] bus_for_each_drv+0x8c/0xe0[ 71.986232] __device_attach+0xb2/0x1e0[ 71.986235] bus_probe_device+0x92/0xb0[ 71.986237] device_add+0x422/0x9a0[ 71.986239] ? _dev_info+0x7d/0x98[ 71.986242] ? blake2s_update+0x4c/0xc0[ 71.986246] usb_new_device.cold+0x148/0x36d[ 71.986250] hub_event+0xa8a/0x1910[ 71.986255] process_one_work+0x1c4/0x380[ 71.986259] worker_thread+0x51/0x390[ 71.986262] ? rescuer_thread+0x3b0/0x3b0[ 71.986264] kthread+0xdb/0x110[ 71.986266] ? kthread_complete_and_exit+0x20/0x20[ 71.986268] ret_from_fork+0x1f/0x30[ 71.986273] [ 71.986274] ---[ end trace 0000000000000000 ]---[ 71.986284] btusb: probe of 2-1.6:1.0 failed with error -17

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: fix memory leak in sctp_stream_outq_migrate()When sctp_stream_outq_migrate() is called to release stream out resources,the memory pointed to by prio_head in stream out is not released.The memory leak information is as follows: unreferenced object 0xffff88801fe79f80 (size 64): comm "sctp_repo", pid 7957, jiffies 4294951704 (age 36.480s) hex dump (first 32 bytes): 80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................ 90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................ backtrace: [] kmalloc_trace+0x26/0x60 [] sctp_sched_prio_set+0x4cc/0x770 [] sctp_stream_init_ext+0xd2/0x1b0 [] sctp_sendmsg_to_asoc+0x1614/0x1a30 [] sctp_sendmsg+0xda1/0x1ef0 [] inet_sendmsg+0x9d/0xe0 [] sock_sendmsg+0xd3/0x120 [] __sys_sendto+0x23a/0x340 [] __x64_sys_sendto+0xe1/0x1b0 [] do_syscall_64+0x39/0xb0 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49017 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: re-fetch skb cb after tipc_msg_validateAs the call trace shows, the original skb was freed in tipc_msg_validate(),and dereferencing the old skb cb would cause an use-after-free crash. BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] Call Trace: tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc] ... Allocated by task 47078: kmem_cache_alloc_node+0x158/0x4d0 __alloc_skb+0x1c1/0x270 tipc_buf_acquire+0x1e/0xe0 [tipc] tipc_msg_create+0x33/0x1c0 [tipc] tipc_link_build_proto_msg+0x38a/0x2100 [tipc] tipc_link_timeout+0x8b8/0xef0 [tipc] tipc_node_timeout+0x2a1/0x960 [tipc] call_timer_fn+0x2d/0x1c0 ... Freed by task 47078: tipc_msg_validate+0x7b/0x440 [tipc] tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc]This patch fixes it by re-fetching the skb cb from the new allocated skbafter calling tipc_msg_validate().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49030 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:libbpf: Handle size overflow for ringbuf mmapThe maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entrieswill overflow u32 when mapping producer page and data pages. Onlycasting max_entries to size_t is not enough, because for 32-bitsapplication on 64-bits kernel the size of read-only mmap regionalso could overflow size_t.So fixing it by casting the size of read-only mmap region into a __u64and checking whether or not there will be overflow during mmap.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49033 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item inbtrfs_run_qgroups() later outside of the spinlock context.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49046 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: dev: check return value when calling dev_set_name()If dev_set_name() fails, the dev_name() is null, check the returnvalue of dev_set_name() to avoid the null-ptr-deref.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49049 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/secretmem: fix panic when growing a memfd_secretWhen one tries to grow an existing memfd_secret with ftruncate, one getsa panic [1]. For example, doing the following reliably induces thepanic: fd = memfd_secret(); ftruncate(fd, 10); ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); strcpy(ptr, "123456789"); munmap(ptr, 10); ftruncate(fd, 20);The basic reason for this is, when we grow with ftruncate, we call downinto simple_setattr, and then truncate_inode_pages_range, and eventuallywe try to zero part of the memory. The normal truncation code does thisvia the direct map (i.e., it calls page_address() and hands that tomemset()).For memfd_secret though, we specifically don't map our pages via thedirect map (i.e. we call set_direct_map_invalid_noflush() on everyfault). So the address returned by page_address() isn't useful, andwhen we try to memset() with it we panic.This patch avoids the panic by implementing a custom setattr formemfd_secret, which detects resizes specifically (setting the size forthe first time works just fine, since there are no existing pages to tryto zero), and rejects them with EINVAL.One could argue growing should be supported, but I think that willrequire a significantly more lengthy change. So, I propose a minimalfix for the benefit of stable kernels, and then perhaps to extendmemfd_secret to support growing in a separate patch.[1]: BUG: unable to handle page fault for address: ffffa0a889277028 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD afa01067 P4D afa01067 PUD 83f909067 PMD 83f8bf067 PTE 800ffffef6d88060 Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 0 PID: 281 Comm: repro Not tainted 5.17.0-dbg-DEV #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:memset_erms+0x9/0x10 Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8 RDX: 0000000000000fd8 RSI: 0000000000000000 RDI: ffffa0a889277028 RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028 R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0 R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8 FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? zero_user_segments+0x82/0x190 truncate_inode_partial_folio+0xd4/0x2a0 truncate_inode_pages_range+0x380/0x830 truncate_setsize+0x63/0x80 simple_setattr+0x37/0x60 notify_change+0x3d8/0x4d0 do_sys_ftruncate+0x162/0x1d0 __x64_sys_ftruncate+0x1c/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: xhci_pci xhci_hcd virtio_net net_failover failover virtio_blk virtio_balloon uhci_hcd ohci_pci ohci_hcd evdev ehci_pci ehci_hcd 9pnet_virtio 9p netfs 9pnet CR2: ffffa0a889277028[lkp@intel.com: secretmem_iops can be static][axelrasmussen@google.com: return EINVAL]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49075 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix qgroup reserve overflow the qgroup limitWe use extent_changeset->bytes_changed in qgroup_reserve_data() to recordhow many bytes we set for EXTENT_QGROUP_RESERVED state. Currently thebytes_changed is set as "unsigned int", and it will overflow if we try tofallocate a range larger than 4GiB. The result is we reserve less bytesand eventually break the qgroup limit.Unlike regular buffered/direct write, which we use one changeset foreach ordered extent, which can never be larger than 256M. Forfallocate, we use one changeset for the whole range, thus it no longerrespects the 256M per extent limit, and caused the problem.The following example test script reproduces the problem: $ cat qgroup-overflow.sh #!/bin/bash DEV=/dev/sdj MNT=/mnt/sdj mkfs.btrfs -f $DEV mount $DEV $MNT # Set qgroup limit to 2GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT # Try to fallocate a 3GiB file. This should fail. echo echo "Try to fallocate a 3GiB file..." fallocate -l 3G $MNT/3G.file # Try to fallocate a 5GiB file. echo echo "Try to fallocate a 5GiB file..." fallocate -l 5G $MNT/5G.file # See we break the qgroup limit. echo sync btrfs qgroup show -r $MNT umount $MNTWhen running the test: $ ./qgroup-overflow.sh (...) Try to fallocate a 3GiB file... fallocate: fallocate failed: Disk quota exceeded Try to fallocate a 5GiB file... qgroupid rfer excl max_rfer -------- ---- ---- -------- 0/5 5.00GiB 5.00GiB 2.00GiBSince we have no control of how bytes_changed is used, it's better toset it to u64.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49087 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: fix a race in rxrpc_exit_net()Current code can lead to the following race:CPU0 CPU1rxrpc_exit_net() rxrpc_peer_keepalive_worker() if (rxnet->live) rxnet->live = false; del_timer_sync(&rxnet->peer_keepalive_timer); timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay); cancel_work_sync(&rxnet->peer_keepalive_work);rxrpc_exit_net() exits while peer_keepalive_timer is still armed,leading to use-after-free.syzbot report was:ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505Modules linked in:CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netRIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __debug_check_no_obj_freed lib/debugobjects.c:992 [inline] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023 kfree+0xd6/0x310 mm/slab.c:3809 ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176 ops_free_list net/core/net_namespace.c:174 [inline] cleanup_net+0x591/0xb00 net/core/net_namespace.c:598 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49094 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/tls: fix slab-out-of-bounds bug in decrypt_internalThe memory size of tls_ctx->rx.iv for AES128-CCM is 12 setting intls_set_sw_offload(). The return value of crypto_aead_ivsize()for "ccm(aes)" is 16. So memcpy() require 16 bytes from 12 bytesmemory space will trigger slab-out-of-bounds bug as following:==================================================================BUG: KASAN: slab-out-of-bounds in decrypt_internal+0x385/0xc40 [tls]Read of size 16 at addr ffff888114e84e60 by task tls/10911Call Trace: dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db ? decrypt_internal+0x385/0xc40 [tls] kasan_report+0xab/0x120 ? decrypt_internal+0x385/0xc40 [tls] kasan_check_range+0xf9/0x1e0 memcpy+0x20/0x60 decrypt_internal+0x385/0xc40 [tls] ? tls_get_rec+0x2e0/0x2e0 [tls] ? process_rx_list+0x1a5/0x420 [tls] ? tls_setup_from_iter.constprop.0+0x2e0/0x2e0 [tls] decrypt_skb_update+0x9d/0x400 [tls] tls_sw_recvmsg+0x3c8/0xb50 [tls]Allocated by task 10911: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 tls_set_sw_offload+0x2eb/0xa20 [tls] tls_setsockopt+0x68c/0x700 [tls] __sys_setsockopt+0xfe/0x1b0Replace the crypto_aead_ivsize() with prot->iv_size + prot->salt_sizewhen memcpy() iv value in TLS_1_3_VERSION scenario.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49123 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ath11k: Fix frames flush failure caused by deadlockWe are seeing below warnings:kernel: [25393.301506] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0kernel: [25398.421509] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0kernel: [25398.421831] ath11k_pci 0000:01:00.0: dropping mgmt frame for vdev 0, is_started 0this means ath11k fails to flush mgmt. frames because wmi_mgmt_tx_workhas no chance to run in 5 seconds.By setting /proc/sys/kernel/hung_task_timeout_secs to 20 and increasingATH11K_FLUSH_TIMEOUT to 50 we get below warnings:kernel: [ 120.763160] INFO: task wpa_supplicant:924 blocked for more than 20 seconds.kernel: [ 120.763169] Not tainted 5.10.90 #12kernel: [ 120.763177] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.kernel: [ 120.763186] task:wpa_supplicant state:D stack: 0 pid: 924 ppid: 1 flags:0x000043a0kernel: [ 120.763201] Call Trace:kernel: [ 120.763214] __schedule+0x785/0x12fakernel: [ 120.763224] ? lockdep_hardirqs_on_prepare+0xe2/0x1bbkernel: [ 120.763242] schedule+0x7e/0xa1kernel: [ 120.763253] schedule_timeout+0x98/0xfekernel: [ 120.763266] ? run_local_timers+0x4a/0x4akernel: [ 120.763291] ath11k_mac_flush_tx_complete+0x197/0x2b1 [ath11k 13c3a9bf37790f4ac8103b3decf7ab4008ac314a]kernel: [ 120.763306] ? init_wait_entry+0x2e/0x2ekernel: [ 120.763343] __ieee80211_flush_queues+0x167/0x21f [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763378] __ieee80211_recalc_idle+0x105/0x125 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763411] ieee80211_recalc_idle+0x14/0x27 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763441] ieee80211_free_chanctx+0x77/0xa2 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763473] __ieee80211_vif_release_channel+0x100/0x131 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763540] ieee80211_vif_release_channel+0x66/0x81 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763572] ieee80211_destroy_auth_data+0xa3/0xe6 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763612] ieee80211_mgd_deauth+0x178/0x29b [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763654] cfg80211_mlme_deauth+0x1a8/0x22c [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]kernel: [ 120.763697] nl80211_deauthenticate+0xfa/0x123 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]kernel: [ 120.763715] genl_rcv_msg+0x392/0x3c2kernel: [ 120.763750] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]kernel: [ 120.763782] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]kernel: [ 120.763802] ? genl_rcv+0x36/0x36kernel: [ 120.763814] netlink_rcv_skb+0x89/0xf7kernel: [ 120.763829] genl_rcv+0x28/0x36kernel: [ 120.763840] netlink_unicast+0x179/0x24bkernel: [ 120.763854] netlink_sendmsg+0x393/0x401kernel: [ 120.763872] sock_sendmsg+0x72/0x76kernel: [ 120.763886] ____sys_sendmsg+0x170/0x1e6kernel: [ 120.763897] ? copy_msghdr_from_user+0x7a/0xa2kernel: [ 120.763914] ___sys_sendmsg+0x95/0xd1kernel: [ 120.763940] __sys_sendmsg+0x85/0xbfkernel: [ 120.763956] do_syscall_64+0x43/0x55kernel: [ 120.763966] entry_SYSCALL_64_after_hwframe+0x44/0xa9kernel: [ 120.763977] RIP: 0033:0x79089f3fcc83kernel: [ 120.763986] RSP: 002b:00007ffe604f0508 EFLAGS: 00000246 ORIG_RAX: 000000000000002ekernel: [ 120.763997] RAX: ffffffffffffffda RBX: 000059b40e987690 RCX: 000079089f3fcc83kernel: [ 120.764006] RDX: 0000000000000000 RSI: 00007ffe604f0558 RDI: 0000000000000009kernel: [ 120.764014] RBP: 00007ffe604f0540 R08: 0000000000000004 R09: 0000000000400000kernel: [ 120.764023] R10: 00007ffe604f0638 R11: 0000000000000246 R12: 000059b40ea04980kernel: [ 120.764032] R13: 00007ffe604---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49133 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: svm range restore work deadlock when process exitkfd_process_notifier_release flush svm_range_restore_workwhich calls svm_range_list_lock_and_flush_work to flush deferred_listwork, but if deferred_list work mmput release the last user, it willcall exit_mmap -> notifier_release, it is deadlock with below backtrace.Move flush svm_range_restore_work to kfd_process_wq_release to avoiddeadlock. Then svm_range_restore_work take task->mm ref to avoid mm isgone while validating and mapping ranges to GPU.Workqueue: events svm_range_deferred_list_work [amdgpu]Call Trace: wait_for_completion+0x94/0x100 __flush_work+0x12a/0x1e0 __cancel_work_timer+0x10e/0x190 cancel_delayed_work_sync+0x13/0x20 kfd_process_notifier_release+0x98/0x2a0 [amdgpu] __mmu_notifier_release+0x74/0x1f0 exit_mmap+0x170/0x200 mmput+0x5d/0x130 svm_range_deferred_list_work+0x104/0x230 [amdgpu] process_one_work+0x220/0x3c0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49134 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum: Guard against invalid local portsWhen processing events generated by the device's firmware, the driverprotects itself from events reported for non-existent local ports, butnot for the CPU port (local port 0), which exists, but does not have allthe fields as any local port.This can result in a NULL pointer dereference when trying access'struct mlxsw_sp_port' fields which are not initialized for CPU port.Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware")already handled such issue by bailing early when processing a PUDE eventreported for the CPU port.Generalize the approach by moving the check to a common function andmaking use of it in all relevant places.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49142 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: preserve skb_end_offset() in skb_unclone_keeptruesize()syzbot found another way to trigger the infamous WARN_ON_ONCE(delta < len)in skb_try_coalesce() [1]I was able to root cause the issue to kfence.When kfence is in action, the following assertion is no longer true:int size = xxxx;void *ptr1 = kmalloc(size, gfp);void *ptr2 = kmalloc(size, gfp);if (ptr1 && ptr2) ASSERT(ksize(ptr1) == ksize(ptr2));We attempted to fix these issues in the blamed commits, but forgotthat TCP was possibly shifting data after skb_unclone_keeptruesize()has been used, notably from tcp_retrans_try_collapse().So we not only need to keep same skb->truesize value,we also need to make sure TCP wont fill new tailroomthat pskb_expand_head() was able to get from aaddr = kmalloc(...) followed by ksize(addr)Split skb_unclone_keeptruesize() into two parts:1) Inline skb_unclone_keeptruesize() for the common case, when skb is not cloned.2) Out of line __skb_unclone_keeptruesize() for the 'slow path'.WARNING: CPU: 1 PID: 6490 at net/core/skbuff.c:5295 skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295Modules linked in:CPU: 1 PID: 6490 Comm: syz-executor161 Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295Code: bf 01 00 00 00 0f b7 c0 89 c6 89 44 24 20 e8 62 24 4e fa 8b 44 24 20 83 e8 01 0f 85 e5 f0 ff ff e9 87 f4 ff ff e8 cb 20 4e fa <0f> 0b e9 06 f9 ff ff e8 af b2 95 fa e9 69 f0 ff ff e8 95 b2 95 faRSP: 0018:ffffc900063af268 EFLAGS: 00010293RAX: 0000000000000000 RBX: 00000000ffffffd5 RCX: 0000000000000000RDX: ffff88806fc05700 RSI: ffffffff872abd55 RDI: 0000000000000003RBP: ffff88806e675500 R08: 00000000ffffffd5 R09: 0000000000000000R10: ffffffff872ab659 R11: 0000000000000000 R12: ffff88806dd554e8R13: ffff88806dd9bac0 R14: ffff88806dd9a2c0 R15: 0000000000000155FS: 00007f18014f9700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020002000 CR3: 000000006be7a000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_try_coalesce net/ipv4/tcp_input.c:4651 [inline] tcp_try_coalesce+0x393/0x920 net/ipv4/tcp_input.c:4630 tcp_queue_rcv+0x8a/0x6e0 net/ipv4/tcp_input.c:4914 tcp_data_queue+0x11fd/0x4bb0 net/ipv4/tcp_input.c:5025 tcp_rcv_established+0x81e/0x1ff0 net/ipv4/tcp_input.c:5947 tcp_v4_do_rcv+0x65e/0x980 net/ipv4/tcp_ipv4.c:1719 sk_backlog_rcv include/net/sock.h:1037 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2779 release_sock+0x54/0x1b0 net/core/sock.c:3311 sk_wait_data+0x177/0x450 net/core/sock.c:2821 tcp_recvmsg_locked+0xe28/0x1fd0 net/ipv4/tcp.c:2457 tcp_recvmsg+0x137/0x610 net/ipv4/tcp.c:2572 inet_recvmsg+0x11b/0x5e0 net/ipv4/af_inet.c:850 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] sock_recvmsg net/socket.c:962 [inline] ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49144 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix memory leak of uid in files registrationWhen there are no files for __io_sqe_files_scm() to process in therange, it'll free everything and return. However, it forgets to put uid.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49149 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix call timer start racing with call destructionThe rxrpc_call struct has a timer used to handle various timed eventsrelating to a call. This timer can get started from the packet inputroutines that are run in softirq mode with just the RCU read lock held.Unfortunately, because only the RCU read lock is held - and neither ref orother lock is taken - the call can start getting destroyed at the same timea packet comes in addressed to that call. This causes the timer - whichwas already stopped - to get restarted. Later, the timer dispatch code maythen oops if the timer got deallocated first.Fix this by trying to take a ref on the rxrpc_call struct and, ifsuccessful, passing that ref along to the timer. If the timer was alreadyrunning, the ref is discarded.The timer completion routine can then pass the ref along to the call's workitem when it queues it. If the timer or work item where alreadyqueued/running, the extra ref is discarded.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49161 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: mediatek: Fix error handling in mt8183_da7219_max98357_dev_probeThe device_node pointer is returned by of_parse_phandle() with refcountincremented. We should use of_node_put() on it when done.This function only calls of_node_put() in the regular path.And it will cause refcount leak in error paths.Fix this by calling of_node_put() in error handling too.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49167 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not double complete bio on errors during compressed readsI hit some weird panics while fixing up the error handling frombtrfs_lookup_bio_sums(). Turns out the compression path will completethe bio we use if we set up any of the compression bios and then returnan error, and then btrfs_submit_data_bio() will also call bio_endio() onthe bio.Fix this by making btrfs_submit_compressed_read() responsible forcalling bio_endio() on the bio if there are any errors. Currently itwas only doing it if we created the compression bios, otherwise it wasdepending on btrfs_submit_data_bio() to do the right thing. Thiscreates the above problem, so fix up btrfs_submit_compressed_read() toalways call bio_endio() in case of an error, and then simply return frombtrfs_submit_data_bio() if we had to callbtrfs_submit_compressed_read().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49168 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not clean up repair bio if submit failsThe submit helper will always run bio_endio() on the bio if it fails tosubmit, so cleaning up the bio just leads to a variety of use-after-freeand NULL pointer dereference bugs because we race with the endiofunction that is cleaning up the bio. Instead just return BLK_STS_OK asthe repair function has to continue to process the rest of the pages,and the endio for the repair bio will do the appropriate cleanup for thepage that it was given.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49178 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:memstick/mspro_block: fix handling of read-only devicesUse set_disk_ro to propagate the read-only state to the block layerinstead of checking for it in ->open and leaking a reference in caseof a read-only device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49190 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmemmemory"), we could get a resource allocated during boot viaalloc_resource(). And it's required to release the resource usingfree_resource(). Howerver, many people use kfree directly which willresult in kernel BUG. In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49191 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mxser: fix xmit_buf leak in activate when LSR == 0xffWhen LSR is 0xff in ->activate() (rather unlike), we return an error.Provided ->shutdown() is not called when ->activate() fails, nothingactually frees the buffer in this case.Fix this by properly freeing the buffer in a designated label. We jumpthere also from the "!info->type" if now too.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49204 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix more uncharged while msg has more_dataIn tcp_bpf_send_verdict(), if msg has more data aftertcp_bpf_sendmsg_redir():tcp_bpf_send_verdict() tosend = msg->sg.size //msg->sg.size = 22220 case __SK_REDIRECT: sk_msg_return() //uncharged msg->sg.size(22220) sk->sk_forward_alloc tcp_bpf_sendmsg_redir() //after tcp_bpf_sendmsg_redir, msg->sg.size=11000 goto more_data; tosend = msg->sg.size //msg->sg.size = 11000 case __SK_REDIRECT: sk_msg_return() //uncharged msg->sg.size(11000) to sk->sk_forward_allocThe msg->sg.size(11000) has been uncharged twice, to fix we can charge theremaining msg->sg.size before goto more data.This issue can cause the following info:WARNING: CPU: 0 PID: 9860 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0Call Trace: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 ? vfs_write+0x237/0x290 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49205 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix double uncharge the mem of sk_msgIf tcp_bpf_sendmsg is running during a tear down operation, psock may befreed.tcp_bpf_sendmsg() tcp_bpf_send_verdict() sk_msg_return() tcp_bpf_sendmsg_redir() unlikely(!psock)) sk_msg_free()The mem of msg has been uncharged in tcp_bpf_send_verdict() bysk_msg_return(), and would be uncharged by sk_msg_free() again. When psockis null, we can simply returning an error code, this would then triggerthe sk_msg_free_nocharge in the error path of __SK_REDIRECT and would havethe side effect of throwing an error up to user space. This would be aslight change in behavior from user side but would look the same as anerror if the redirect on the socket threw an error.This issue can cause the following info:WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49207 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix memleak in sk_psock_queue_msgIf tcp_bpf_sendmsg is running during a tear down operation we may enqueuedata on the ingress msg queue while tear down is trying to free it. sk1 (redirect sk2) sk2 ------------------- ---------------tcp_bpf_sendmsg() tcp_bpf_send_verdict() tcp_bpf_sendmsg_redir() bpf_tcp_ingress() sock_map_close() lock_sock() lock_sock() ... blocking sk_psock_stop sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED); release_sock(sk); lock_sock() sk_mem_charge() get_page() sk_psock_queue_msg() sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED); drop_sk_msg() release_sock()While drop_sk_msg(), the msg has charged memory form sk by sk_mem_chargeand has sg pages need to put. To fix we use sk_msg_free() and then kfee()msg.This issue can cause the following info:WARNING: CPU: 0 PID: 9202 at net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0Call Trace: inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xe5f/0xe90 ? sk_filter_trim_cap+0x10d/0x230 ? tcp_v4_do_rcv+0x161/0x250 tcp_v4_do_rcv+0x161/0x250 tcp_v4_rcv+0xc3a/0xce0 ip_protocol_deliver_rcu+0x3d/0x230 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0xfd/0x110 ? ip_protocol_deliver_rcu+0x230/0x230 ip_rcv+0xd6/0x100 ? ip_local_deliver+0x110/0x110 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0xa4/0x160 __napi_poll+0x29/0x1b0 net_rx_action+0x287/0x300 __do_softirq+0xff/0x2fc do_softirq+0x79/0x90 WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 ? process_one_work+0x3c0/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49209 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is fullIf tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partialmemory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size isgreater than osize after sk_msg_alloc(), memleak occurs. To fix we usesk_msg_trim() to release the allocated memory, then goto wait for memory.Other call paths of sk_msg_alloc() have the similar issue, such astls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),as Cong Wang suggested.This issue can cause the following info:WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0Call Trace: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 kthread+0xe6/0x110 ret_from_fork+0x22/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49215 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Fix race at socket teardownFix a race in the xsk socket teardown code that can lead to a NULL pointerdereference splat. The current xsk unbind code in xsk_unbind_dev() starts bysetting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for anyNAPI processing to terminate using synchronize_net(). After that, the releasecode starts to tear down the socket state and free allocated memory. BUG: kernel NULL pointer dereference, address: 00000000000000c0 PGD 8000000932469067 P4D 8000000932469067 PUD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2 Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015 RIP: 0010:__xsk_sendmsg+0x2c/0x690 [...] RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258 RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800 RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800 R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000 FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0 Call Trace: ? aa_sk_perm+0x43/0x1b0 xsk_sendmsg+0xf0/0x110 sock_sendmsg+0x65/0x70 __sys_sendto+0x113/0x190 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x23/0x50 ? exit_to_user_mode_prepare+0xa5/0x1d0 __x64_sys_sendto+0x29/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xaeThere are two problems with the current code. First, setting xs->dev to NULLbefore waiting for all users to stop using the socket is not correct. Theentry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()are all guarded by a test that xs->state is in the state XSK_BOUND and if not,it returns right away. But one process might have passed this test but stillhave not gotten to the point in which it uses xs->dev in the code. In thisinterim, a second process executing xsk_unbind_dev() might have set xs->dev toNULL which will lead to a crash for the first process. The solution here isjust to get rid of this NULL assignment since it is not used anymore. Beforecommit 42fddcc7c64b ("xsk: use state member for socket synchronization"),xs->dev was the gatekeeper to admit processes into the data plane functions,but it was replaced with the state variable xs->state in the aforementionedcommit.The second problem is that synchronize_net() does not wait for any process inxsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that thestate they rely on might be cleaned up prematurely. This can happen when thenotifier gets called (at driver unload for example) as it uses xsk_unbind_dev().Solve this by extending the RCU critical region from just the ndo_xsk_wakeupto the whole functions mentioned above, so that both the test of xs->state ==XSK_BOUND and the last use of any member of xs is covered by the RCU criticalsection. This will guarantee that when synchronize_net() completes, there willbe no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() andstate can be cleaned up safely. Note that we need to drop the RCU lock for theskb xmit path as it uses functions that might sleep. Due to this, we have toretest the xs->state after we grab the mutex that protects the skb xmit codefrom, among a number of things, an xsk_unbind_dev() being executed from thenotifier at the same time.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49219 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: fix memory leak during D3hot to D0 transitionIf 'vfio_pci_core_device::needs_pm_restore' is set (PCI device doesnot have No_Soft_Reset bit set in its PMCSR config register), thenthe current PCI state will be saved locally in'vfio_pci_core_device::pm_save' during D0->D3hot transition and samewill be restored back during D3hot->D0 transition.For saving the PCI state locally, pci_store_saved_state() is beingused and the pci_load_and_free_saved_state() will free the allocatedmemory.But for reset related IOCTLs, vfio driver calls PCI reset-relatedAPI's which will internally change the PCI power state back to D0. So,when the guest resumes, then it will get the current state as D0 and itwill skip the call to vfio_pci_set_power_state() for changing thepower state to D0 explicitly. In this case, the memory pointed by'pm_save' will never be freed. In a malicious sequence, the state changingto D3hot followed by VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET can berun in a loop and it can cause an OOM situation.This patch frees the earlier allocated memory first before overwriting'pm_save' to prevent the mentioned memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49220 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dax: make sure inodes are flushed before destroy cacheA bug can be triggered by following command$ modprobe nd_pmem && modprobe -r nd_pmem[ 10.060014] BUG dax_cache (Not tainted): Objects remaining in dax_cache on __kmem_cache_shutdown()[ 10.060938] Slab 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node)[ 10.062433] Call Trace:[ 10.062673] dump_stack_lvl+0x34/0x44[ 10.062865] slab_err+0x90/0xd0[ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0[ 10.063848] kmem_cache_destroy+0x4a/0x110[ 10.064058] __x64_sys_delete_module+0x265/0x300This is caused by dax_fs_exit() not flushing inodes before destroy cache.To fix this issue, call rcu_barrier() before destroy cache.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49223 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cxl/port: Hold port reference until decoder releaseKASAN + DEBUG_KOBJECT_RELEASE reports a potential use-after-free incxl_decoder_release() where it goes to reference its parent, a cxl_port,to free its id back to port->decoder_ida. BUG: KASAN: use-after-free in to_cxl_port+0x18/0x90 [cxl_core] Read of size 8 at addr ffff888119270908 by task kworker/35:2/379 CPU: 35 PID: 379 Comm: kworker/35:2 Tainted: G OE 5.17.0-rc2+ #198 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events kobject_delayed_cleanup Call Trace: dump_stack_lvl+0x59/0x73 print_address_description.constprop.0+0x1f/0x150 ? to_cxl_port+0x18/0x90 [cxl_core] kasan_report.cold+0x83/0xdf ? to_cxl_port+0x18/0x90 [cxl_core] to_cxl_port+0x18/0x90 [cxl_core] cxl_decoder_release+0x2a/0x60 [cxl_core] device_release+0x5f/0x100 kobject_cleanup+0x80/0x1c0The device core only guarantees parent lifetime until all children areunregistered. If a child needs a parent to complete its ->release()callback that child needs to hold a reference to extend the lifetime ofthe parent.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49229 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ptp: unregister virtual clocks when unregistering physical clock.When unregistering a physical clock which has some virtual clocks,unregister the virtual clocks with it.This fixes the following oops, which can be triggered by unloadinga driver providing a PTP clock when it has enabled virtual clocks:BUG: unable to handle page fault for address: ffffffffc04fc4d8Oops: 0000 [#1] PREEMPT SMP NOPTIRIP: 0010:ptp_vclock_read+0x31/0xb0Call Trace: timecounter_read+0xf/0x50 ptp_vclock_refresh+0x2c/0x50 ? ptp_clock_release+0x40/0x40 ptp_aux_kworker+0x17/0x30 kthread_worker_fn+0x9b/0x240 ? kthread_should_park+0x30/0x30 kthread+0xe2/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49234 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: Avoid cross-chip syncing of VLAN filteringChanges to VLAN filtering are not applicable to cross-chipnotifications.On a system like this:.-----. .-----. .-----.| sw1 +---+ sw2 +---+ sw3 |'-1-2-' '-1-2-' '-1-2-'Before this change, upon sw1p1 leaving a bridge, a call todsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.In this scenario:.---------. .-----. .-----.| sw1 +---+ sw2 +---+ sw3 |'-1-2-3-4-' '-1-2-' '-1-2-'When sw1p4 would leave a bridge, dsa_port_vlan_filtering would becalled for sw2 and sw3 with a non-existing port - leading to arrayout-of-bounds accesses and crashes on mv88e6xxx.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49282 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: quota: fix loop condition at f2fs_quota_sync()cnt should be passed to sb_has_quota_active() instead of type to checkactive quota properly.Moreover, when the type is -1, the compiler with enough inline knowledgecan discard sb_has_quota_active() check altogether, causing a NULL pointerdereference at the following inode_lock(dqopt->files[cnt]):[ 2.796010] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0[ 2.796024] Mem abort info:[ 2.796025] ESR = 0x96000005[ 2.796028] EC = 0x25: DABT (current EL), IL = 32 bits[ 2.796029] SET = 0, FnV = 0[ 2.796031] EA = 0, S1PTW = 0[ 2.796032] Data abort info:[ 2.796034] ISV = 0, ISS = 0x00000005[ 2.796035] CM = 0, WnR = 0[ 2.796046] user pgtable: 4k pages, 39-bit VAs, pgdp=00000003370d1000[ 2.796048] [00000000000000a0] pgd=0000000000000000, pud=0000000000000000[ 2.796051] Internal error: Oops: 96000005 [#1] PREEMPT SMP[ 2.796056] CPU: 7 PID: 640 Comm: f2fs_ckpt-259:7 Tainted: G S 5.4.179-arter97-r8-64666-g2f16e087f9d8 #1[ 2.796057] Hardware name: Qualcomm Technologies, Inc. Lahaina MTP lemonadep (DT)[ 2.796059] pstate: 80c00005 (Nzcv daif +PAN +UAO)[ 2.796065] pc : down_write+0x28/0x70[ 2.796070] lr : f2fs_quota_sync+0x100/0x294[ 2.796071] sp : ffffffa3f48ffc30[ 2.796073] x29: ffffffa3f48ffc30 x28: 0000000000000000[ 2.796075] x27: ffffffa3f6d718b8 x26: ffffffa415fe9d80[ 2.796077] x25: ffffffa3f7290048 x24: 0000000000000001[ 2.796078] x23: 0000000000000000 x22: ffffffa3f7290000[ 2.796080] x21: ffffffa3f72904a0 x20: ffffffa3f7290110[ 2.796081] x19: ffffffa3f77a9800 x18: ffffffc020aae038[ 2.796083] x17: ffffffa40e38e040 x16: ffffffa40e38e6d0[ 2.796085] x15: ffffffa40e38e6cc x14: ffffffa40e38e6d0[ 2.796086] x13: 00000000000004f6 x12: 00162c44ff493000[ 2.796088] x11: 0000000000000400 x10: ffffffa40e38c948[ 2.796090] x9 : 0000000000000000 x8 : 00000000000000a0[ 2.796091] x7 : 0000000000000000 x6 : 0000d1060f00002a[ 2.796093] x5 : ffffffa3f48ff718 x4 : 000000000000000d[ 2.796094] x3 : 00000000060c0000 x2 : 0000000000000001[ 2.796096] x1 : 0000000000000000 x0 : 00000000000000a0[ 2.796098] Call trace:[ 2.796100] down_write+0x28/0x70[ 2.796102] f2fs_quota_sync+0x100/0x294[ 2.796104] block_operations+0x120/0x204[ 2.796106] f2fs_write_checkpoint+0x11c/0x520[ 2.796107] __checkpoint_and_complete_reqs+0x7c/0xd34[ 2.796109] issue_checkpoint_thread+0x6c/0xb8[ 2.796112] kthread+0x138/0x414[ 2.796114] ret_from_fork+0x10/0x18[ 2.796117] Code: aa0803e0 aa1f03e1 52800022 aa0103e9 (c8e97d02)[ 2.796120] ---[ end trace 96e942e8eb6a0b53 ]---[ 2.800116] Kernel panic - not syncing: Fatal exception[ 2.800120] SMP: stopping secondary CPUs

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49325 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: add accessors to read/set tp->snd_cwndWe had various bugs over the years with codebreaking the assumption that tp->snd_cwnd is greaterthan zero.Lately, syzbot reported the WARN_ON_ONCE(!tp->prior_cwnd) addedin commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction")can trigger, and without a repro we would have to spendconsiderable time finding the bug.Instead of complaining too late, we want to catch whereand when tp->snd_cwnd is set to an illegal value.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49330 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix tcp_mtup_probe_success vs wrong snd_cwndsyzbot got a new report [1] finally pointing to a very old bug,added in initial support for MTU probing.tcp_mtu_probe() has checks about starting an MTU probe iftcp_snd_cwnd(tp) >= 11.But nothing prevents tcp_snd_cwnd(tp) to be reduced laterand before the MTU probe succeeds.This bug would lead to potential zero-divides.Debugging added in commit 40570375356c ("tcp: add accessorsto read/set tp->snd_cwnd") has paid off :)While we are at it, address potential overflows in this code.[1]WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712Modules linked in:CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ffRSP: 0018:ffffc900079e70f8 EFLAGS: 00010287RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9fRBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356 tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861 tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973 tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x1d8/0x4c0 net/core/sock.c:2849 release_sock+0x5d/0x1c0 net/core/sock.c:3404 sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145 tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410 tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] __sys_sendto+0x439/0x5c0 net/socket.c:2119 __do_sys_sendto net/socket.c:2131 [inline] __se_sys_sendto net/socket.c:2127 [inline] __x64_sys_sendto+0xda/0xf0 net/socket.c:2127 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0RIP: 0033:0x7f6431289109Code: 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 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000aRBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49333 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: E-Switch, pair only capable devicesOFFLOADS paring using devcom is possible only on devicesthat support LAG. Filter based on lag capabilities.This fixes an issue where mlx5_get_next_phys_dev() wascalled without holding the interface lock.This issue was found when commitbc4c2f2e0179 ("net/mlx5: Lag, filter non compatible devices")added an assert that verifies the interface lock is held.WARNING: CPU: 9 PID: 1706 at drivers/net/ethernet/mellanox/mlx5/core/dev.c:642 mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core]Modules linked in: mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm ib_uverbs ib_core overlay fuse [last unloaded: mlx5_core]CPU: 9 PID: 1706 Comm: devlink Not tainted 5.18.0-rc7+ #11Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core]Code: 02 00 75 48 48 8b 85 80 04 00 00 5d c3 31 c0 5d c3 be ff ff ff ff 48 c7 c7 08 41 5b a0 e8 36 87 28 e3 85 c0 0f 85 6f ff ff ff <0f> 0b e9 68 ff ff ff 48 c7 c7 0c 91 cc 84 e8 cb 36 6f e1 e9 4d ffRSP: 0018:ffff88811bf47458 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff88811b398000 RCX: 0000000000000001RDX: 0000000080000000 RSI: ffffffffa05b4108 RDI: ffff88812daaaa78RBP: ffff88812d050380 R08: 0000000000000001 R09: ffff88811d6b3437R10: 0000000000000001 R11: 00000000fddd3581 R12: ffff88815238c000R13: ffff88812d050380 R14: ffff8881018aa7e0 R15: ffff88811d6b3428FS: 00007fc82e18ae80(0000) GS:ffff88842e080000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f9630d1b421 CR3: 0000000149802004 CR4: 0000000000370ea0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: mlx5_esw_offloads_devcom_event+0x99/0x3b0 [mlx5_core] mlx5_devcom_send_event+0x167/0x1d0 [mlx5_core] esw_offloads_enable+0x1153/0x1500 [mlx5_core] ? mlx5_esw_offloads_controller_valid+0x170/0x170 [mlx5_core] ? wait_for_completion_io_timeout+0x20/0x20 ? mlx5_rescan_drivers_locked+0x318/0x810 [mlx5_core] mlx5_eswitch_enable_locked+0x586/0xc50 [mlx5_core] ? mlx5_eswitch_disable_pf_vf_vports+0x1d0/0x1d0 [mlx5_core] ? mlx5_esw_try_lock+0x1b/0xb0 [mlx5_core] ? mlx5_eswitch_enable+0x270/0x270 [mlx5_core] ? __debugfs_create_file+0x260/0x3e0 mlx5_devlink_eswitch_mode_set+0x27e/0x870 [mlx5_core] ? mutex_lock_io_nested+0x12c0/0x12c0 ? esw_offloads_disable+0x250/0x250 [mlx5_core] ? devlink_nl_cmd_trap_get_dumpit+0x470/0x470 ? rcu_read_lock_sched_held+0x3f/0x70 devlink_nl_cmd_eswitch_set_doit+0x217/0x620

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49340 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ip_gre: test csum_start instead of transport headerGRE with TUNNEL_CSUM will apply local checksum offload onCHECKSUM_PARTIAL packets.ipgre_xmit must validate csum_start after an optional skb_pull,else lco_csum may trigger an overflow. The original check was if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL;This had false positives when skb_checksum_start is undefined:when ip_summed is not CHECKSUM_PARTIAL. A discussed refinementwas straightforward if (csum && skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start(skb) < skb->data) return -EINVAL;But was eventually revised more thoroughly:- restrict the check to the only branch where needed, in an uncommon GRE path that uses header_ops and calls skb_pull.- test skb_transport_header, which is set along with csum_start in skb_partial_csum_set in the normal header_ops datapath.Turns out skbs can arrive in this branch without the transportheader set, e.g., through BPF redirection.Revise the check back to check csum_start directly, and only ifCHECKSUM_PARTIAL. Do leave the check in the updated location.Check field regardless of whether TUNNEL_CSUM is configured.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49344 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix a data-race in unix_dgram_peer_wake_me().unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'slock held and check if its receive queue is full. Here we need touse unix_recvq_full_lockless() instead of unix_recvq_full(), otherwiseKCSAN will report a data-race.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49358 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: memleak flow rule from commit pathAbort path release flow rule object, however, commit path does not.Update code to destroy these objects before releasing the transaction.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49359 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panfrost: Job should reference MMU not file_privFor a while now it's been allowed for a MMU context to outlive it'scorresponding panfrost_priv, however the job structure still referencespanfrost_priv to get hold of the MMU context. If panfrost_priv has beenfreed this is a use-after-free which I've been able to trigger resultingin a splat.To fix this, drop the reference to panfrost_priv in the job structureand add a direct reference to the MMU structure which is what's actuallyneeded.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49372 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: tcp_rtx_synack() can be called from process contextLaurent reported the enclosed report [1]This bug triggers with following coditions:0) Kernel built with CONFIG_DEBUG_PREEMPT=y1) A new passive FastOpen TCP socket is created. This FO socket waits for an ACK coming from client to be a complete ESTABLISHED one.2) A socket operation on this socket goes through lock_sock() release_sock() dance.3) While the socket is owned by the user in step 2), a retransmit of the SYN is received and stored in socket backlog.4) At release_sock() time, the socket backlog is processed while in process context.5) A SYNACK packet is cooked in response of the SYN retransmit.6) -> tcp_rtx_synack() is called in process context.Before blamed commit, tcp_rtx_synack() was always called from BH handler,from a timer handler.Fix this by using TCP_INC_STATS() & NET_INC_STATS()which do not assume caller is in non preemptible context.[1]BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180caller is tcp_rtx_synack.part.0+0x36/0xc0CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021Call Trace: dump_stack_lvl+0x48/0x5e check_preemption_disabled+0xde/0xe0 tcp_rtx_synack.part.0+0x36/0xc0 tcp_rtx_synack+0x8d/0xa0 ? kmem_cache_alloc+0x2e0/0x3e0 ? apparmor_file_alloc_security+0x3b/0x1f0 inet_rtx_syn_ack+0x16/0x30 tcp_check_req+0x367/0x610 tcp_rcv_state_process+0x91/0xf60 ? get_nohz_timer_target+0x18/0x1a0 ? lock_timer_base+0x61/0x80 ? preempt_count_add+0x68/0xa0 tcp_v4_do_rcv+0xbd/0x270 __release_sock+0x6d/0xb0 release_sock+0x2b/0x90 sock_setsockopt+0x138/0x1140 ? __sys_getsockname+0x7e/0xc0 ? aa_sk_perm+0x3e/0x1a0 __sys_setsockopt+0x198/0x1e0 __x64_sys_setsockopt+0x21/0x30 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49374 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: check attribute length for bearer namesyzbot reported uninit-value:=====================================================BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline]BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:644 [inline] string+0x4f9/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283 vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50 _printk+0x18d/0x1cf kernel/printk/printk.c:2293 tipc_enable_bearer net/tipc/bearer.c:371 [inline] __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033 tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]- Do sanity check the attribute length for TIPC_NLA_BEARER_NAME.- Do not use 'illegal name' in printing message.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49388 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ubi: ubi_create_volume: Fix use-after-free when volume creation failedThere is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'serror handling path: ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tblout_mapping: ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl'out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAFFix it by removing redundant 'eba_tbl' releasing.Fetch a reproducer in [Link].

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49390 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:macsec: fix UAF bug for real_devCreate a new macsec device but not get reference to real_dev. That cannot ensure that real_dev is freed after macsec. That will trigger theUAF bug for real_dev as following:==================================================================BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327After commit faab39f63c1f ("net: allow out-of-order netdev unregistration")and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), wecan add dev_hold_track() in macsec_dev_init() and dev_put_track() inmacsec_free_netdev() to fix the problem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49395 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:um: Fix out-of-bounds read in LDT setupsyscall_stub_data() expects the data_count parameter to be the number oflongs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ==================================================================

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49420 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: annotate races around sk->sk_bound_dev_ifUDP sendmsg() is lockless, and reads sk->sk_bound_dev_if whilethis field can be changed by another thread.Adds minimal annotations to avoid KCSAN splats for UDP.Following patches will add more annotations to potential lockless readers.BUG: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsgwrite to 0xffff888136d47a94 of 4 bytes by task 7681 on cpu 0: __ip6_datagram_connect+0x6e2/0x930 net/ipv6/datagram.c:221 ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576 __sys_connect_file net/socket.c:1900 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeread to 0xffff888136d47a94 of 4 bytes by task 7670 on cpu 1: udpv6_sendmsg+0xc60/0x16e0 net/ipv6/udp.c:1436 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:652 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2413 ___sys_sendmsg net/socket.c:2467 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2553 __do_sys_sendmmsg net/socket.c:2582 [inline] __se_sys_sendmmsg net/socket.c:2579 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaevalue changed: 0x00000000 -> 0xffffff9bReported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 7670 Comm: syz-executor.3 Tainted: G W 5.18.0-rc1-syzkaller-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011I chose to not add Fixes: tag because race has minor consequencesand stable teams busy enough.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49439 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/fsl_rio: Fix refcount leak in fsl_rio_setupof_parse_phandle() returns a node pointer with refcountincremented, we should use of_node_put() on it when not need anymore.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49446 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvdimm: Fix firmware activation deadlock scenariosLockdep reports the following deadlock scenarios for CXL root devicepower-management, device_prepare(), operations, and device_shutdown()operations for 'nd_region' devices: Chain exists of: &nvdimm_region_key --> &nvdimm_bus->reconfig_mutex --> system_transition_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(system_transition_mutex); lock(&nvdimm_bus->reconfig_mutex); lock(system_transition_mutex); lock(&nvdimm_region_key); Chain exists of: &cxl_nvdimm_bridge_key --> acpi_scan_lock --> &cxl_root_key Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&cxl_root_key); lock(acpi_scan_lock); lock(&cxl_root_key); lock(&cxl_nvdimm_bridge_key);These stem from holding nvdimm_bus_lock() over hibernate_quiet_exec()which walks the entire system device topology taking device_lock() alongthe way. The nvdimm_bus_lock() is protecting against unregistration,multiple simultaneous ops callers, and preventing activate_show() fromracing activate_store(). For the first 2, the lock is redundant.Unregistration already flushes all ops users, and sysfs already preventsmultiple threads to be active in an ops handler at the same time. Forthe last userspace should already be waiting for its lastactivate_store() to complete, and does not need activate_show() to flushthe write side, so this lock usage can be deleted in these attributes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49450 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix listen() setting the bar too high for the prealloc ringsAF_RXRPC's listen() handler lets you set the backlog up to 32 (if you bumpup the sysctl), but whilst the preallocation circular buffers have 32 slotsin them, one of them has to be a dead slot because we're using CIRC_CNT().This means that listen(rxrpc_sock, 32) will cause an oops when the socketis closed because rxrpc_service_prealloc_one() allocated one too many callsand rxrpc_discard_prealloc() won't then be able to get rid of them becauseit'll think the ring is empty. rxrpc_release_calls_on_socket() then triesto abort them, but oopses because call->peer isn't yet set.Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to matchthe ring capacity. BUG: kernel NULL pointer dereference, address: 0000000000000086 ... RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc] Call Trace: ? __wake_up_common_lock+0x7a/0x90 ? rxrpc_notify_socket+0x8e/0x140 [rxrpc] ? rxrpc_abort_call+0x4c/0x60 [rxrpc] rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc] rxrpc_release+0xc9/0x1c0 [rxrpc] __sock_release+0x37/0xa0 sock_close+0x11/0x20 __fput+0x89/0x240 task_work_run+0x59/0x90 do_exit+0x319/0xaa0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49469 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix anon_dev leak in create_subvol()When btrfs_qgroup_inherit(), btrfs_alloc_tree_block, orbtrfs_insert_root() fail in create_subvol(), we return without freeinganon_dev. Reorganize the error handling in create_subvol() to fix this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49470 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btmtksdio: fix use-after-free at btmtksdio_recv_eventWe should not access skb buffer data anymore after hci_recv_frame wascalled.[ 39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0[ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker[ 39.634962] Call trace:[ 39.634974] dump_backtrace+0x0/0x3b8[ 39.634999] show_stack+0x20/0x2c[ 39.635016] dump_stack_lvl+0x60/0x78[ 39.635040] print_address_description+0x70/0x2f0[ 39.635062] kasan_report+0x154/0x194[ 39.635079] __asan_report_load1_noabort+0x44/0x50[ 39.635099] btmtksdio_recv_event+0x1b0/0x1c4[ 39.635129] btmtksdio_txrx_work+0x6cc/0xac4[ 39.635157] process_one_work+0x560/0xc5c[ 39.635177] worker_thread+0x7ec/0xcc0[ 39.635195] kthread+0x2d0/0x3d0[ 39.635215] ret_from_fork+0x10/0x20[ 39.635247] Allocated by task 0:[ 39.635260] (stack is not available)[ 39.635281] Freed by task 2392:[ 39.635295] kasan_save_stack+0x38/0x68[ 39.635319] kasan_set_track+0x28/0x3c[ 39.635338] kasan_set_free_info+0x28/0x4c[ 39.635357] ____kasan_slab_free+0x104/0x150[ 39.635374] __kasan_slab_free+0x18/0x28[ 39.635391] slab_free_freelist_hook+0x114/0x248[ 39.635410] kfree+0xf8/0x2b4[ 39.635427] skb_free_head+0x58/0x98[ 39.635447] skb_release_data+0x2f4/0x410[ 39.635464] skb_release_all+0x50/0x60[ 39.635481] kfree_skb+0xc8/0x25c[ 39.635498] hci_event_packet+0x894/0xca4 [bluetooth][ 39.635721] hci_rx_work+0x1c8/0x68c [bluetooth][ 39.635925] process_one_work+0x560/0xc5c[ 39.635951] worker_thread+0x7ec/0xcc0[ 39.635970] kthread+0x2d0/0x3d0[ 39.635990] ret_from_fork+0x10/0x20[ 39.636021] The buggy address belongs to the object at ffffff80cf28a600 which belongs to the cache kmalloc-512 of size 512[ 39.636039] The buggy address is located 13 bytes inside of 512-byte region [ffffff80cf28a600, ffffff80cf28a800)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49471 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rtw89: cfo: check mac_id to avoid out-of-boundsSomehow, hardware reports incorrect mac_id and pollute memory. Check indexbefore we access the array. UBSAN: array-index-out-of-bounds in rtw89/phy.c:2517:23 index 188 is out of range for type 's32 [64]' CPU: 1 PID: 51550 Comm: irq/35-rtw89_pc Tainted: G OE Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x4c/0x63 dump_stack+0x10/0x12 ubsan_epilogue+0x9/0x45 __ubsan_handle_out_of_bounds.cold+0x44/0x49 ? __alloc_skb+0x92/0x1d0 rtw89_phy_cfo_parse+0x44/0x7f [rtw89_core] rtw89_core_rx+0x261/0x871 [rtw89_core] ? __alloc_skb+0xee/0x1d0 rtw89_pci_napi_poll+0x3fa/0x4ea [rtw89_pci] __napi_poll+0x33/0x1a0 net_rx_action+0x126/0x260 ? __queue_work+0x217/0x4c0 __do_softirq+0xd9/0x315 ? disable_irq_nosync+0x10/0x10 do_softirq.part.0+0x6d/0x90 __local_bh_enable_ip+0x62/0x70 rtw89_pci_interrupt_threadfn+0x182/0x1a6 [rtw89_pci] irq_thread_fn+0x28/0x60 irq_thread+0xc8/0x190 ? irq_thread_fn+0x60/0x60 kthread+0x16b/0x190 ? irq_thread_check_affinity+0xe0/0xe0 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49476 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7921: fix kernel crash at mt7921_pci_removeThe crash log shown it is possible that mt7921_irq_handler is called whiledevm_free_irq is being handled so mt76_free_device need to be postponeduntil devm_free_irq is completed to solve the crash we free the mt76 devicetoo early.[ 9299.339655] BUG: kernel NULL pointer dereference, address: 0000000000000008[ 9299.339705] #PF: supervisor read access in kernel mode[ 9299.339735] #PF: error_code(0x0000) - not-present page[ 9299.339768] PGD 0 P4D 0[ 9299.339786] Oops: 0000 [#1] SMP PTI[ 9299.339812] CPU: 1 PID: 1624 Comm: prepare-suspend Not tainted 5.15.14-1.fc32.qubes.x86_64 #1[ 9299.339863] Hardware name: Xen HVM domU, BIOS 4.14.3 01/20/2022[ 9299.339901] RIP: 0010:mt7921_irq_handler+0x1e/0x70 [mt7921e][ 9299.340048] RSP: 0018:ffffa81b80c27cb0 EFLAGS: 00010082[ 9299.340081] RAX: 0000000000000000 RBX: ffff98a4cb752020 RCX: ffffffffa96211c5[ 9299.340123] RDX: 0000000000000000 RSI: 00000000000d4204 RDI: ffff98a4cb752020[ 9299.340165] RBP: ffff98a4c28a62a4 R08: ffff98a4c37a96c0 R09: 0000000080150011[ 9299.340207] R10: 0000000040000000 R11: 0000000000000000 R12: ffff98a4c4eaa080[ 9299.340249] R13: ffff98a4c28a6360 R14: ffff98a4cb752020 R15: ffff98a4c28a6228[ 9299.340297] FS: 00007260840d3740(0000) GS:ffff98a4ef700000(0000) knlGS:0000000000000000[ 9299.340345] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 9299.340383] CR2: 0000000000000008 CR3: 0000000004c56001 CR4: 0000000000770ee0[ 9299.340432] PKRU: 55555554[ 9299.340449] Call Trace:[ 9299.340467] [ 9299.340485] __free_irq+0x221/0x350[ 9299.340527] free_irq+0x30/0x70[ 9299.340553] devm_free_irq+0x55/0x80[ 9299.340579] mt7921_pci_remove+0x2f/0x40 [mt7921e][ 9299.340616] pci_device_remove+0x3b/0xa0[ 9299.340651] __device_release_driver+0x17a/0x240[ 9299.340686] device_driver_detach+0x3c/0xa0[ 9299.340714] unbind_store+0x113/0x130[ 9299.340740] kernfs_fop_write_iter+0x124/0x1b0[ 9299.340775] new_sync_write+0x15c/0x1f0[ 9299.340806] vfs_write+0x1d2/0x270[ 9299.340831] ksys_write+0x67/0xe0[ 9299.340857] do_syscall_64+0x3b/0x90[ 9299.340887] entry_SYSCALL_64_after_hwframe+0x44/0xae

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49484 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7915: fix possible NULL pointer dereference in mt7915_mac_fill_rx_vectorFix possible NULL pointer dereference in mt7915_mac_fill_rx_vectorroutine if the chip does not support dbdc and the hw reports band_idxset to 1.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49496 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: prevent kernel crash when rmmod mtk-vcodec-dec.koIf the driver support subdev mode, the parameter "dev->pm.dev" will beNULL in mtk_vcodec_dec_remove. Kernel will crash when try to rmmodmtk-vcodec-dec.ko.[ 4380.702726] pc : do_raw_spin_trylock+0x4/0x80[ 4380.707075] lr : _raw_spin_lock_irq+0x90/0x14c[ 4380.711509] sp : ffff80000819bc10[ 4380.714811] x29: ffff80000819bc10 x28: ffff3600c03e4000 x27: 0000000000000000[ 4380.721934] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000[ 4380.729057] x23: ffff3600c0f34930 x22: ffffd5e923549000 x21: 0000000000000220[ 4380.736179] x20: 0000000000000208 x19: ffffd5e9213e8ebc x18: 0000000000000020[ 4380.743298] x17: 0000002000000000 x16: ffffd5e9213e8e90 x15: 696c346f65646976[ 4380.750420] x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000040[ 4380.757542] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000[ 4380.764664] x8 : 0000000000000000 x7 : ffff3600c7273ae8 x6 : ffffd5e9213e8ebc[ 4380.771786] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000[ 4380.778908] x2 : 0000000000000000 x1 : ffff3600c03e4000 x0 : 0000000000000208[ 4380.786031] Call trace:[ 4380.788465] do_raw_spin_trylock+0x4/0x80[ 4380.792462] __pm_runtime_disable+0x2c/0x1b0[ 4380.796723] mtk_vcodec_dec_remove+0x5c/0xa0 [mtk_vcodec_dec][ 4380.802466] platform_remove+0x2c/0x60[ 4380.806204] __device_release_driver+0x194/0x250[ 4380.810810] driver_detach+0xc8/0x15c[ 4380.814462] bus_remove_driver+0x5c/0xb0[ 4380.818375] driver_unregister+0x34/0x64[ 4380.822288] platform_driver_unregister+0x18/0x24[ 4380.826979] mtk_vcodec_dec_driver_exit+0x1c/0x888 [mtk_vcodec_dec][ 4380.833240] __arm64_sys_delete_module+0x190/0x224[ 4380.838020] invoke_syscall+0x48/0x114[ 4380.841760] el0_svc_common.constprop.0+0x60/0x11c[ 4380.846540] do_el0_svc+0x28/0x90[ 4380.849844] el0_svc+0x4c/0x100[ 4380.852975] el0t_64_sync_handler+0xec/0xf0[ 4380.857148] el0t_64_sync+0x190/0x194[ 4380.860801] Code: 94431515 17ffffca d503201f d503245f (b9400004)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49497 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: remove two BUG() from skb_checksum_help()I have a syzbot report that managed to get a crash in skb_checksum_help()If syzbot can trigger these BUG(), it makes sense to replacethem with more friendly WARN_ON_ONCE() since skb_checksum_help()can instead return an error code.Note that syzbot will still crash there, until real bug is fixed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49513 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: governor: Use kobject release() method to free dbs_dataThe struct dbs_data embeds a struct gov_attr_set andthe struct gov_attr_set embeds a kobject. Since every kobject must havea release() method and we can't use kfree() to free it directly,so introduce cpufreq_dbs_data_release() to release the dbs_data viathe kobject::release() method. This fixes the calltrace like below: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [] __irq_exit_rcu+0x108/0x1a4[ rjw: Because can be freed by the gov_attr_set_put() in cpufreq_dbs_governor_exit() now, it is also necessary to put the invocation of the governor ->exit() callback into the new cpufreq_dbs_data_release() function. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49516 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: always check VF VSI pointer valuesThe ice_get_vf_vsi function can return NULL in some cases, such as ifhandling messages during a reset where the VSI is being removed andrecreated.Several places throughout the driver do not bother to check whether thisVSI pointer is valid. Static analysis tools maybe report issues becausethey detect paths where a potentially NULL pointer could be dereferenced.Fix this by checking the return value of ice_get_vf_vsi everywhere.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49528 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: dw9714: Disable the regulator when the driver fails to probeWhen the driver fails to probe, we will get the following splat:[ 59.305988] ------------[ cut here ]------------[ 59.306417] WARNING: CPU: 2 PID: 395 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0[ 59.310345] RIP: 0010:_regulator_put+0x3ec/0x4e0[ 59.318362] Call Trace:[ 59.318582] [ 59.318765] regulator_put+0x1f/0x30[ 59.319058] devres_release_group+0x319/0x3d0[ 59.319420] i2c_device_probe+0x766/0x940Fix this by disabling the regulator in error handling.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49530 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix double free in si_parse_power_table()In function si_parse_power_table(), array adev->pm.dpm.ps and its memberis allocated. If the allocation of each member fails, the array itselfis freed and returned with an error code. However, the array is laterfreed again in si_dpm_fini() function which is called when the functionreturns an error.This leads to potential double free of the array adev->pm.dpm.ps, aswell as leak of its array members, since the members are not freed inthe allocation function and the array is not nulled when freed.In addition adev->pm.dpm.num_ps, which keeps track of the allocatedarray member, is not updated until the member allocation issuccessfully finished, this could also lead to either use after free,or uninitialized variable access in si_dpm_fini().Fix this by postponing the free of the array until si_dpm_fini() andincrement adev->pm.dpm.num_ps everytime the array member is allocated.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49533 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ath11k: Change max no of active probe SSID and BSSID to fw capabilityThe maximum number of SSIDs in a for active probe requests is currentlyreported as 16 (WLAN_SCAN_PARAMS_MAX_SSID) when registering the driver.The scan_req_params structure only has the capacity to hold 10 SSIDs.This leads to a buffer overflow which can be triggered fromwpa_supplicant in userspace. When copying the SSIDs into thescan_req_params structure in the ath11k_mac_op_hw_scan route, it canoverwrite the extraie pointer.Firmware supports 16 ssid * 4 bssid, for each ssid 4 bssid combo proberequest will be sent, so totally 64 probe requests supported. Soset both max ssid and bssid to 16 and 4 respectively. Remove theredundant macros of ssid and bssid.Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01300-QCAHKSWPL_SILICONZ-1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49538 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: jack: Access input_dev under mutexIt is possible when using ASoC that input_dev is unregistered whilecalling snd_jack_report, which causes NULL pointer dereference.In order to prevent this serialize access to input_dev using mutex lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49543 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ath11k: fix the warning of dev_wake in mhi_pm_disable_transition()When test device recovery with below command, it has warning in messageas below.echo assert > /sys/kernel/debug/ath11k/wcn6855\ hw2.0/simulate_fw_crashecho assert > /sys/kernel/debug/ath11k/qca6390\ hw2.0/simulate_fw_crashwarning message:[ 1965.642121] ath11k_pci 0000:06:00.0: simulating firmware assert crash[ 1968.471364] ieee80211 phy0: Hardware restart was requested[ 1968.511305] ------------[ cut here ]------------[ 1968.511368] WARNING: CPU: 3 PID: 1546 at drivers/bus/mhi/core/pm.c:505 mhi_pm_disable_transition+0xb37/0xda0 [mhi][ 1968.511443] Modules linked in: ath11k_pci ath11k mac80211 libarc4 cfg80211 qmi_helpers qrtr_mhi mhi qrtr nvme nvme_core[ 1968.511563] CPU: 3 PID: 1546 Comm: kworker/u17:0 Kdump: loaded Tainted: G W 5.17.0-rc3-wt-ath+ #579[ 1968.511629] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021[ 1968.511704] Workqueue: mhi_hiprio_wq mhi_pm_st_worker [mhi][ 1968.511787] RIP: 0010:mhi_pm_disable_transition+0xb37/0xda0 [mhi][ 1968.511870] Code: a9 fe ff ff 4c 89 ff 44 89 04 24 e8 03 46 f6 e5 44 8b 04 24 41 83 f8 01 0f 84 21 fe ff ff e9 4c fd ff ff 0f 0b e9 af f8 ff ff <0f> 0b e9 5c f8 ff ff 48 89 df e8 da 9e ee e3 e9 12 fd ff ff 4c 89[ 1968.511923] RSP: 0018:ffffc900024efbf0 EFLAGS: 00010286[ 1968.511969] RAX: 00000000ffffffff RBX: ffff88811d241250 RCX: ffffffffc0176922[ 1968.512014] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff888118a90a24[ 1968.512059] RBP: ffff888118a90800 R08: 0000000000000000 R09: ffff888118a90a27[ 1968.512102] R10: ffffed1023152144 R11: 0000000000000001 R12: ffff888118a908ac[ 1968.512229] R13: ffff888118a90928 R14: dffffc0000000000 R15: ffff888118a90a24[ 1968.512310] FS: 0000000000000000(0000) GS:ffff888234200000(0000) knlGS:0000000000000000[ 1968.512405] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1968.512493] CR2: 00007f5538f443a8 CR3: 000000016dc28001 CR4: 00000000003706e0[ 1968.512587] Call Trace:[ 1968.512672] [ 1968.512751] ? _raw_spin_unlock_irq+0x1f/0x40[ 1968.512859] mhi_pm_st_worker+0x3ac/0x790 [mhi][ 1968.512959] ? mhi_pm_mission_mode_transition.isra.0+0x7d0/0x7d0 [mhi][ 1968.513063] process_one_work+0x86a/0x1400[ 1968.513184] ? pwq_dec_nr_in_flight+0x230/0x230[ 1968.513312] ? move_linked_works+0x125/0x290[ 1968.513416] worker_thread+0x6db/0xf60[ 1968.513536] ? process_one_work+0x1400/0x1400[ 1968.513627] kthread+0x241/0x2d0[ 1968.513733] ? kthread_complete_and_exit+0x20/0x20[ 1968.513821] ret_from_fork+0x22/0x30[ 1968.513924] Reason is mhi_deassert_dev_wake() from mhi_device_put() is calledbut mhi_assert_dev_wake() from __mhi_device_get_sync() is not calledin progress of recovery. Commit 8e0559921f9a ("bus: mhi: core:Skip device wake in error or shutdown state") add check for thepm_state of mhi in __mhi_device_get_sync(), and the pm_state is notthe normal state untill recovery is completed, so it leads thedev_wake is not 0 and above warning print in mhi_pm_disable_transition()while checking mhi_cntrl->dev_wake.Add check in ath11k_pci_write32()/ath11k_pci_read32() to skip callmhi_device_put() if mhi_device_get_sync() does not really do wake,then the warning gone.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49548 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix potential array overflow in bpf_trampoline_get_progs()The cnt value in the 'cnt >= BPF_MAX_TRAMP_PROGS' check does notinclude BPF_TRAMP_MODIFY_RETURN bpf programs, so the number ofthe attached BPF_TRAMP_MODIFY_RETURN bpf programs in a trampolinecan exceed BPF_MAX_TRAMP_PROGS.When this happens, the assignment '*progs++ = aux->prog' inbpf_trampoline_get_progs() will cause progs array overflow as theprogs field in the bpf_tramp_progs struct can only hold at mostBPF_MAX_TRAMP_PROGS bpf programs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49552 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix combination of jit blinding and pointers to bpf subprogs.The combination of jit blinding and pointers to bpf subprogs causes:[ 36.989548] BUG: unable to handle page fault for address: 0000000100000001[ 36.990342] #PF: supervisor instruction fetch in kernel mode[ 36.990968] #PF: error_code(0x0010) - not-present page[ 36.994859] RIP: 0010:0x100000001[ 36.995209] Code: Unable to access opcode bytes at RIP 0xffffffd7.[ 37.004091] Call Trace:[ 37.004351] [ 37.004576] ? bpf_loop+0x4d/0x70[ 37.004932] ? bpf_prog_3899083f75e4c5de_F+0xe3/0x13bThe jit blinding logic didn't recognize that ld_imm64 with an addressof bpf subprogram is a special instruction and proceeded to randomize it.By itself it wouldn't have been an issue, but jit_subprogs() logicrelies on two step process to JIT all subprogs and then JIT themagain when addresses of all subprogs are known.Blinding process in the first JIT phase caused second JIT to missadjustment of special ld_imm64.Fix this issue by ignoring special ld_imm64 instructions that don't haveuser controlled constants and shouldn't be blinded.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49554 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:zsmalloc: fix races between asynchronous zspage free and page migrationThe asynchronous zspage free worker tries to lock a zspage's entire pagelist without defending against page migration. Since pages which haven'tyet been locked can concurrently migrate off the zspage page list whilelock_zspage() churns away, lock_zspage() can suffer from a few differentlethal races.It can lock a page which no longer belongs to the zspage and unsafelydereference page_private(), it can unsafely dereference a torn pointer tothe next page (since there's a data race), and it can observe a spuriousNULL pointer to the next page and thus not lock all of the zspage's pages(since a single page migration will reconstruct the entire page list, andcreate_page_chain() unconditionally zeroes out each list pointer in theprocess).Fix the races by using migrate_read_lock() in lock_zspage() to synchronizewith page migration.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49558 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: double hook unregistration in netns path__nft_release_hooks() is called from pre_netns exit path whichunregisters the hooks, then the NETDEV_UNREGISTER event is triggeredwhich unregisters the hooks again.[ 565.221461] WARNING: CPU: 18 PID: 193 at net/netfilter/core.c:495 __nf_unregister_net_hook+0x247/0x270[...][ 565.246890] CPU: 18 PID: 193 Comm: kworker/u64:1 Tainted: G E 5.18.0-rc7+ #27[ 565.253682] Workqueue: netns cleanup_net[ 565.257059] RIP: 0010:__nf_unregister_net_hook+0x247/0x270[...][ 565.297120] Call Trace:[ 565.300900] [ 565.304683] nf_tables_flowtable_event+0x16a/0x220 [nf_tables][ 565.308518] raw_notifier_call_chain+0x63/0x80[ 565.312386] unregister_netdevice_many+0x54f/0xb50Unregister and destroy netdev hook from netns pre_exit via kfree_rcuso the NETDEV_UNREGISTER path see unregistered hooks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49560 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: check if cluster num is validSyzbot reported slab-out-of-bounds read in exfat_clear_bitmap.This was triggered by reproducer calling truncute with size 0,which causes the following trace:BUG: KASAN: slab-out-of-bounds in exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174Read of size 8 at addr ffff888115aa9508 by task syz-executor251/365Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack_lvl+0x1e2/0x24b lib/dump_stack.c:118 print_address_description+0x81/0x3c0 mm/kasan/report.c:233 __kasan_report mm/kasan/report.c:419 [inline] kasan_report+0x1a4/0x1f0 mm/kasan/report.c:436 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309 exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 exfat_free_cluster+0x25a/0x4a0 fs/exfat/fatent.c:181 __exfat_truncate+0x99e/0xe00 fs/exfat/file.c:217 exfat_truncate+0x11b/0x4f0 fs/exfat/file.c:243 exfat_setattr+0xa03/0xd40 fs/exfat/file.c:339 notify_change+0xb76/0xe10 fs/attr.c:336 do_truncate+0x1ea/0x2d0 fs/open.c:65Move the is_valid_cluster() helper from fatent.c to a commonheader to make it reusable in other *.c files. And add is_valid_cluster()to validate if cluster number is within valid range in exfat_clear_bitmap()and exfat_set_bitmap().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49561 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: re-fetch conntrack after insertionIn case the conntrack is clashing, insertion can free skb->_nfct andset skb->_nfct to the already-confirmed entry.This wasn't found before because the conntrack entry and the extensionspace used to free'd after an rcu grace period, plus the race needsevents enabled to trigger.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49576 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: Fix data-races around sysctl_fib_multipath_hash_fields.While reading sysctl_fib_multipath_hash_fields, it can be changedconcurrently. Thus, we need to add READ_ONCE() to its readers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49588 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Fix data-races around sysctl_tcp_migrate_req.While reading sysctl_tcp_migrate_req, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49589 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:igmp: Fix data-races around sysctl_igmp_qrv.While reading sysctl_igmp_qrv, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.This test can be packed into a helper, so such changes will be in thefollow-up series after net is merged into net-next. qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv);

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49594 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Fix a data-race around sysctl_tcp_mtu_probe_floor.While reading sysctl_tcp_mtu_probe_floor, it can be changed concurrently.Thus, we need to add READ_ONCE() to its reader.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49600 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ip: Fix a data-race around sysctl_ip_autobind_reuse.While reading sysctl_ip_autobind_reuse, it can be changed concurrently.Thus, we need to add READ_ONCE() to its reader.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49608 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: ralink: Check for null return of devm_kcallocBecause of the possible failure of the allocation, data->domains mightbe NULL pointer and will cause the dereference of the NULL pointerlater.Therefore, it might be better to check it and directly return -ENOMEMwithout releasing data manually if fails, because the comment of thedevm_kmalloc() says "Memory allocated with this function isautomatically freed on driver detach.".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49622 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: avoid skb access on nf_stolenWhen verdict is NF_STOLEN, the skb might have been freed.When tracing is enabled, this can result in a use-after-free:1. access to skb->nf_trace2. access to skb->mark3. computation of trace id4. dump of packet payloadTo avoid 1, keep a cached copy of skb->nf_trace in thetrace state struct.Refresh this copy whenever verdict is != STOLEN.Avoid 2 by skipping skb->mark access if verdict is STOLEN.3 is avoided by precomputing the trace id.Only dump the packet when verdict is not "STOLEN".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49629 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nexthop: Fix data-races around nexthop_compat_mode.While reading nexthop_compat_mode, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49633 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:icmp: Fix data-races around sysctl_icmp_echo_enable_probe.While reading sysctl_icmp_echo_enable_probe, it can be changedconcurrently. Thus, we need to add READ_ONCE() to its readers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49635 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/selftests: fix subtraction overflow bugOn some machines hole_end can be small enough to cause subtractionoverflow. On the other side (addr + 2 * min_alignment) can overflowin case of mock tests. This patch should handle both cases.(cherry picked from commit ab3edc679c552a466e4bf0b11af3666008bd65a2)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49637 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: Fix a data-race around sysctl_fib_sync_mem.While reading sysctl_fib_sync_mem, it can be changed concurrently.So, we need to add READ_ONCE() to avoid a data-race.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49654 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: qca8k: reset cpu port on MTU changeIt was discovered that the Documentation lacks of a fundamental detailon how to correctly change the MAX_FRAME_SIZE of the switch.In fact if the MAX_FRAME_SIZE is changed while the cpu port is on, theswitch panics and cease to send any packet. This cause the mgmt ethernetsystem to not receive any packet (the slow fallback still works) andmakes the device not reachable. To recover from this a switch reset isrequired.To correctly handle this, turn off the cpu ports before changing theMAX_FRAME_SIZE and turn on again after the value is applied.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49658 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_valsKuee reported a corner case where the tnum becomes constant after the callto __reg_bound_offset(), but the register's bounds are not, that is, itsmin bounds are still not equal to the register's max bounds.This in turn allows to leak pointers through turning a pointer register asis into an unknown scalar via adjust_ptr_min_max_vals().Before: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) 2: (87) r3 = -r3 ; R3_w=scalar() 3: (87) r3 = -r3 ; R3_w=scalar() 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881) 5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 6: (95) exit from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 8: (95) exit from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 9: (07) r3 += -32767 ; R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)) <--- [*] 10: (95) exitWhat can be seen here is that R3=scalar(umin=32767,umax=32768,var_off=(0x7fff;0x8000)) after the operation R3 += -32767 results in a 'malformed' constant, thatis, R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)). Intersecting with var_off hasnot been done at that point via __update_reg_bounds(), which would have improvedthe umax to be equal to umin.Refactor the tnum <> min/max bounds information flow into a reg_bounds_sync()helper and use it consistently everywhere. After the fix, bounds have beencorrected to R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) and thus the registeris regarded as a 'proper' constant scalar of 0.After: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) 2: (87) r3 = -r3 ; R3_w=scalar() 3: (87) r3 = -r3 ; R3_w=scalar() 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881) 5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 6: (95) exit from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 8: (95) exit from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49659 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: m_can: m_can_{read_fifo,echo_tx_event}(): shift timestamp to full 32 bitsIn commit 1be37d3b0414 ("can: m_can: fix periph RX path: userx-offload to ensure skbs are sent from softirq context") the RX pathfor peripheral devices was switched to RX-offload.Received CAN frames are pushed to RX-offload together with atimestamp. RX-offload is designed to handle overflows of the timestampcorrectly, if 32 bit timestamps are provided.The timestamps of m_can core are only 16 bits wide. So this patchshifts them to full 32 bit before passing them to RX-offload.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49662 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix lockdep splat in in6_dump_addrs()As reported by syzbot, we should not use rcu_dereference()when rcu_read_lock() is not held.WARNING: suspicious RCU usage5.19.0-rc2-syzkaller #0 Not taintednet/ipv6/addrconf.c:5175 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by syz-executor326/3617: #0: ffffffff8d5848e8 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xae/0xc20 net/netlink/af_netlink.c:2223stack backtrace:CPU: 0 PID: 3617 Comm: syz-executor326 Not tainted 5.19.0-rc2-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 in6_dump_addrs+0x12d1/0x1790 net/ipv6/addrconf.c:5175 inet6_dump_addr+0x9c1/0xb50 net/ipv6/addrconf.c:5300 netlink_dump+0x541/0xc20 net/netlink/af_netlink.c:2275 __netlink_dump_start+0x647/0x900 net/netlink/af_netlink.c:2380 netlink_dump_start include/linux/netlink.h:245 [inline] rtnetlink_rcv_msg+0x73e/0xc90 net/core/rtnetlink.c:6046 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492 ___sys_sendmsg+0xf3/0x170 net/socket.c:2546 __sys_sendmsg net/socket.c:2575 [inline] __do_sys_sendmsg net/socket.c:2584 [inline] __se_sys_sendmsg net/socket.c:2582 [inline] __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49664 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: move bc link creation back to tipc_node_createShuang Li reported a NULL pointer dereference crash: [] BUG: kernel NULL pointer dereference, address: 0000000000000068 [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc] [] Call Trace: [] [] tipc_bcast_rcv+0xa2/0x190 [tipc] [] tipc_node_bc_rcv+0x8b/0x200 [tipc] [] tipc_rcv+0x3af/0x5b0 [tipc] [] tipc_udp_recv+0xc7/0x1e0 [tipc]It was caused by the 'l' passed into tipc_bcast_rcv() is NULL. When itcreates a node in tipc_node_check_dest(), after inserting the new nodeinto hashtable in tipc_node_create(), it creates the bc link. However,there is a gap between this insert and bc link creation, a bc packetmay come in and get the node from the hashtable then try to dereferenceits bc link, which is NULL.This patch is to fix it by moving the bc link creation before insertinginto the hashtable.Note that for a preliminary node becoming "real", the bc link creationshould also be called before it's rehashed, as we don't create it forpreliminary nodes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49691 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erspan: do not assume transport header is always setRewrite tests in ip6erspan_tunnel_xmit() anderspan_fb_xmit() to not assume transport header is set.syzbot reported:WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 skb_transport_header include/linux/skbuff.h:2911 [inline]WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963Modules linked in:CPU: 0 PID: 1350 Comm: aoe_tx0 Not tainted 5.19.0-rc2-syzkaller-00160-g274295c6e53f #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014RIP: 0010:skb_transport_header include/linux/skbuff.h:2911 [inline]RIP: 0010:ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963Code: 0f 47 f0 40 88 b5 7f fe ff ff e8 8c 16 4b f9 89 de bf ff ff ff ff e8 a0 12 4b f9 66 83 fb ff 0f 85 1d f1 ff ff e8 71 16 4b f9 <0f> 0b e9 43 f0 ff ff e8 65 16 4b f9 48 8d 85 30 ff ff ff ba 60 00RSP: 0018:ffffc90005daf910 EFLAGS: 00010293RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000RDX: ffff88801f032100 RSI: ffffffff882e8d3f RDI: 0000000000000003RBP: ffffc90005dafab8 R08: 0000000000000003 R09: 000000000000ffffR10: 000000000000ffff R11: 0000000000000000 R12: ffff888024f21d40R13: 000000000000a288 R14: 00000000000000b0 R15: ffff888025a2e000FS: 0000000000000000(0000) GS:ffff88802c800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b2e425000 CR3: 000000006d099000 CR4: 0000000000152ef0Call Trace:__netdev_start_xmit include/linux/netdevice.h:4805 [inline]netdev_start_xmit include/linux/netdevice.h:4819 [inline]xmit_one net/core/dev.c:3588 [inline]dev_hard_start_xmit+0x188/0x880 net/core/dev.c:3604sch_direct_xmit+0x19f/0xbe0 net/sched/sch_generic.c:342__dev_xmit_skb net/core/dev.c:3815 [inline]__dev_queue_xmit+0x14a1/0x3900 net/core/dev.c:4219dev_queue_xmit include/linux/netdevice.h:2994 [inline]tx+0x6a/0xc0 drivers/block/aoe/aoenet.c:63kthread+0x1e7/0x3b0 drivers/block/aoe/aoecmd.c:1229kthread+0x2e9/0x3a0 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49696 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix use-after-free Read in tipc_named_reinitsyzbot found the following issue on:==================================================================BUG: KASAN: use-after-free in tipc_named_reinit+0x94f/0x9b0net/tipc/name_distr.c:413Read of size 8 at addr ffff88805299a000 by task kworker/1:9/23764CPU: 1 PID: 23764 Comm: kworker/1:9 Not tainted5.18.0-rc4-syzkaller-00878-g17d49e6e8012 #0Hardware name: Google Compute Engine/Google Compute Engine,BIOS Google 01/01/2011Workqueue: events tipc_net_finalize_workCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xeb/0x495mm/kasan/report.c:313 print_report mm/kasan/report.c:429 [inline] kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491 tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413 tipc_net_finalize+0x234/0x3d0 net/tipc/net.c:138 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298 [...]==================================================================In the commitd966ddcc3821 ("tipc: fix a deadlock when flushing scheduled work"),the cancel_work_sync() function just to make sure ONLY the worktipc_net_finalize_work() is executing/pending on any CPU completed beforetipc namespace is destroyed through tipc_exit_net(). But this functionis not guaranteed the work is the last queued. So, the destroyed instancemay be accessed in the work which will try to enqueue later.In order to completely fix, we re-order the calling of cancel_work_sync()to make sure the work tipc_net_finalize_work() was last queued and itmust be completed by calling cancel_work_sync().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49697 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix request_sock leak in sk lookup helpersA customer reported a request_socket leak in a Calico cloud environment. Wefound that a BPF program was doing a socket lookup with takes a refcnt onthe socket and that it was finding the request_socket but returning the parentLISTEN socket via sk_to_full_sk() without decrementing the child request socket1st, resulting in request_sock slab object leak. This patch retains theexisting behaviour of returning full socks to the caller but it also decrementsthe child request_socket if one is present before doing so to prevent the leak.Thanks to Curtis Taylor for all the help in diagnosing and testing this. Andthanks to Antoine Tenart for the reproducer and patch input.v2 of this patch contains, refactor as per Daniel Borkmann's suggestions tovalidate RCU flags on the listen socket so that it balances with bpf_sk_release()and update comments as per Martin KaFai Lau's suggestion. One small change toDaniels suggestion, put "sk = sk2" under "if (sk2 != sk)" to avoid an extrainstruction.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49702 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix hang during unmount when block group reclaim task is runningWhen we start an unmount, at close_ctree(), if we have the reclaim taskrunning and in the middle of a data block group relocation, we can triggera deadlock when stopping an async reclaim task, producing a trace like thefollowing:[629724.498185] task:kworker/u16:7 state:D stack: 0 pid:681170 ppid: 2 flags:0x00004000[629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs][629724.501267] Call Trace:[629724.501759] [629724.502174] __schedule+0x3cb/0xed0[629724.502842] schedule+0x4e/0xb0[629724.503447] btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs][629724.504534] ? prepare_to_wait_exclusive+0xc0/0xc0[629724.505442] flush_space+0x423/0x630 [btrfs][629724.506296] ? rcu_read_unlock_trace_special+0x20/0x50[629724.507259] ? lock_release+0x220/0x4a0[629724.507932] ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs][629724.508940] ? do_raw_spin_unlock+0x4b/0xa0[629724.509688] btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs][629724.510922] process_one_work+0x252/0x5a0[629724.511694] ? process_one_work+0x5a0/0x5a0[629724.512508] worker_thread+0x52/0x3b0[629724.513220] ? process_one_work+0x5a0/0x5a0[629724.514021] kthread+0xf2/0x120[629724.514627] ? kthread_complete_and_exit+0x20/0x20[629724.515526] ret_from_fork+0x22/0x30[629724.516236] [629724.516694] task:umount state:D stack: 0 pid:719055 ppid:695412 flags:0x00004000[629724.518269] Call Trace:[629724.518746] [629724.519160] __schedule+0x3cb/0xed0[629724.519835] schedule+0x4e/0xb0[629724.520467] schedule_timeout+0xed/0x130[629724.521221] ? lock_release+0x220/0x4a0[629724.521946] ? lock_acquired+0x19c/0x420[629724.522662] ? trace_hardirqs_on+0x1b/0xe0[629724.523411] __wait_for_common+0xaf/0x1f0[629724.524189] ? usleep_range_state+0xb0/0xb0[629724.524997] __flush_work+0x26d/0x530[629724.525698] ? flush_workqueue_prep_pwqs+0x140/0x140[629724.526580] ? lock_acquire+0x1a0/0x310[629724.527324] __cancel_work_timer+0x137/0x1c0[629724.528190] close_ctree+0xfd/0x531 [btrfs][629724.529000] ? evict_inodes+0x166/0x1c0[629724.529510] generic_shutdown_super+0x74/0x120[629724.530103] kill_anon_super+0x14/0x30[629724.530611] btrfs_kill_super+0x12/0x20 [btrfs][629724.531246] deactivate_locked_super+0x31/0xa0[629724.531817] cleanup_mnt+0x147/0x1c0[629724.532319] task_work_run+0x5c/0xa0[629724.532984] exit_to_user_mode_prepare+0x1a6/0x1b0[629724.533598] syscall_exit_to_user_mode+0x16/0x40[629724.534200] do_syscall_64+0x48/0x90[629724.534667] entry_SYSCALL_64_after_hwframe+0x44/0xae[629724.535318] RIP: 0033:0x7fa2b90437a7[629724.535804] RSP: 002b:00007ffe0b7e4458 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6[629724.536912] RAX: 0000000000000000 RBX: 00007fa2b9182264 RCX: 00007fa2b90437a7[629724.538156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000555d6cf20dd0[629724.539053] RBP: 0000555d6cf20ba0 R08: 0000000000000000 R09: 00007ffe0b7e3200[629724.539956] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000[629724.540883] R13: 0000555d6cf20dd0 R14: 0000555d6cf20cb0 R15: 0000000000000000[629724.541796] This happens because:1) Before entering close_ctree() we have the async block group reclaim task running and relocating a data block group;2) There's an async metadata (or data) space reclaim task running;3) We enter close_ctree() and park the cleaner kthread;4) The async space reclaim task is at flush_space() and runs all the existing delayed iputs;5) Before the async space reclaim task calls btrfs_wait_on_delayed_iputs(), the block group reclaim task which is doing the data block group relocation, creates a delayed iput at replace_file_extents() (called when COWing leaves that have file extent items pointing to relocated data exten---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49706 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:zonefs: fix zonefs_iomap_begin() for readsIf a readahead is issued to a sequential zone file with an offsetexactly equal to the current file size, the iomap type is set toIOMAP_UNWRITTEN, which will prevent an IO, but the iomap length iscalculated as 0. This causes a WARN_ON() in iomap_iter():[17309.548939] WARNING: CPU: 3 PID: 2137 at fs/iomap/iter.c:34 iomap_iter+0x9cf/0xe80[...][17309.650907] RIP: 0010:iomap_iter+0x9cf/0xe80[...][17309.754560] Call Trace:[17309.757078] [17309.759240] ? lock_is_held_type+0xd8/0x130[17309.763531] iomap_readahead+0x1a8/0x870[17309.767550] ? iomap_read_folio+0x4c0/0x4c0[17309.771817] ? lockdep_hardirqs_on_prepare+0x400/0x400[17309.778848] ? lock_release+0x370/0x750[17309.784462] ? folio_add_lru+0x217/0x3f0[17309.790220] ? reacquire_held_locks+0x4e0/0x4e0[17309.796543] read_pages+0x17d/0xb60[17309.801854] ? folio_add_lru+0x238/0x3f0[17309.807573] ? readahead_expand+0x5f0/0x5f0[17309.813554] ? policy_node+0xb5/0x140[17309.819018] page_cache_ra_unbounded+0x27d/0x450[17309.825439] filemap_get_pages+0x500/0x1450[17309.831444] ? filemap_add_folio+0x140/0x140[17309.837519] ? lock_is_held_type+0xd8/0x130[17309.843509] filemap_read+0x28c/0x9f0[17309.848953] ? zonefs_file_read_iter+0x1ea/0x4d0 [zonefs][17309.856162] ? trace_contention_end+0xd6/0x130[17309.862416] ? __mutex_lock+0x221/0x1480[17309.868151] ? zonefs_file_read_iter+0x166/0x4d0 [zonefs][17309.875364] ? filemap_get_pages+0x1450/0x1450[17309.881647] ? __mutex_unlock_slowpath+0x15e/0x620[17309.888248] ? wait_for_completion_io_timeout+0x20/0x20[17309.895231] ? lock_is_held_type+0xd8/0x130[17309.901115] ? lock_is_held_type+0xd8/0x130[17309.906934] zonefs_file_read_iter+0x356/0x4d0 [zonefs][17309.913750] new_sync_read+0x2d8/0x520[17309.919035] ? __x64_sys_lseek+0x1d0/0x1d0Furthermore, this causes iomap_readahead() to loop forever asiomap_readahead_iter() always returns 0, making no progress.Fix this by treating reads after the file size as access to holes,setting the iomap type to IOMAP_HOLE, the iomap addr to IOMAP_NULL_ADDRand using the length argument as is for the iomap length. To simplifythe code with this change, zonefs_iomap_begin() is split into the readvariant, zonefs_read_iomap_begin() and zonefs_read_iomap_ops, and thewrite variant, zonefs_write_iomap_begin() and zonefs_write_iomap_ops.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49709 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cfi: Fix __cfi_slowpath_diag RCU usage with cpuidleRCU_NONIDLE usage during __cfi_slowpath_diag can result in an invalidRCU state in the cpuidle code path: WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:613 rcu_eqs_enter+0xe4/0x138 ... Call trace: rcu_eqs_enter+0xe4/0x138 rcu_idle_enter+0xa8/0x100 cpuidle_enter_state+0x154/0x3a8 cpuidle_enter+0x3c/0x58 do_idle.llvm.6590768638138871020+0x1f4/0x2ec cpu_startup_entry+0x28/0x2c secondary_start_kernel+0x1b8/0x220 __secondary_switched+0x94/0x98Instead, call rcu_irq_enter/exit to wake up RCU only when needed anddisable interrupts for the entire CFI shadow/module check when we do.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49732 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sock: redo the psock vs ULP protection checkCommit 8a59f9d1e3d4 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()")has moved the inet_csk_has_ulp(sk) check from sk_psock_init() tothe new tcp_bpf_update_proto() function. I'm guessing that thiswas done to allow creating psocks for non-inet sockets.Unfortunately the destruction path for psock includes the ULPunwind, so we need to fail the sk_psock_init() itself.Otherwise if ULP is already present we'll notice that later,and call tcp_update_ulp() with the sk_proto of the ULPitself, which will most likely result in the ULP loopingits callbacks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49743 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ovl: Use "buf" flexible array for memcpy() destinationThe "buf" flexible array needs to be the memcpy() destination to avoidfalse positive run-time warning from the recent FORTIFY_SOURCEhardening: memcpy: detected field-spanning write (size 93) of single field "&fh->fb" at fs/overlayfs/export.c:799 (size 21)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49749 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: designware: use casting of u64 in clock multiplication to avoid overflowIn functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflowby depending on the values of the given parameters including the ic_clk.For example in our use case where ic_clk is larger than one million,multiplication of ic_clk * 4700 will result in 32 bit overflow.Add cast of u64 to the calculation to avoid multiplication overflow, anduse the corresponding define for divide.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49757 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/highbank: Fix memory leak in highbank_mc_probe()When devres_open_group() fails, it returns -ENOMEM without freeing memoryallocated by edac_mc_alloc().Call edac_mc_free() on the error handling path to avoid a memory leak. [ bp: Massage commit message. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49758 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:reset: uniphier-glue: Fix possible null-ptr-derefIt will cause null-ptr-deref when resource_size(res) invoked,if platform_get_resource() returns NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49761 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: always report error in run_one_delayed_ref()Currently we have a btrfs_debug() for run_one_delayed_ref() failure, butif end users hit such problem, there will be no chance thatbtrfs_debug() is enabled. This can lead to very little useful info fordebugging.This patch will:- Add extra info for error reporting Including: * logical bytenr * num_bytes * type * action * ref_mod- Replace the btrfs_debug() with btrfs_err()- Move the error reporting into run_one_delayed_ref() This is to avoid use-after-free, the @node can be freed in the caller.This error should only be triggered at most once.As if run_one_delayed_ref() failed, we trigger the error message, thencausing the call chain to error out:btrfs_run_delayed_refs()`- btrfs_run_delayed_refs() `- btrfs_run_delayed_refs_for_head() `- run_one_delayed_ref()And we will abort the current transaction in btrfs_run_delayed_refs().If we have to run delayed refs for the abort transaction,run_one_delayed_ref() will just cleanup the refs and do nothing, thus nonew error messages would be output.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49762 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ntfs: check overflow when iterating ATTR_RECORDsKernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find(). Because the ATTR_RECORDs are next to each other, kernel can get the nextATTR_RECORD from end address of current ATTR_RECORD, through currentATTR_RECORD length field.The problem is that during iteration, when kernel calculates the endaddress of current ATTR_RECORD, kernel may trigger an integer overflow bugin executing `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`. Thismay wrap, leading to a forever iteration on 32bit systems.This patch solves it by adding some checks on calculating end addressof current ATTR_RECORD during iteration.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49764 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Prevent bpf program recursion for raw tracepoint probesWe got report from sysbot [1] about warnings that were caused bybpf program attached to contention_begin raw tracepoint triggeringthe same tracepoint by using bpf_trace_printk helper that takestrace_printk_lock lock. Call Trace: ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90 bpf_trace_printk+0x2b/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 __unfreeze_partials+0x5b/0x160 ...The can be reproduced by attaching bpf program as raw tracepoint oncontention_begin tracepoint. The bpf prog calls bpf_trace_printkhelper. Then by running perf bench the spin lock code is forced totake slow path and call contention_begin tracepoint.Fixing this by skipping execution of the bpf program if it'salready running, Using bpf prog 'active' field, which is beingcurrently used by trampoline programs for the same reason.Moving bpf_prog_inc_misses_counter to syscall.c becausetrampoline.c is compiled in just for CONFIG_BPF_JIT option.[1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49765 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: use a dedicated spinlock for trans_fdShamelessly copying the explanation from Tetsuo Handa's suggestedpatch[1] (slightly reworded):syzbot is reporting inconsistent lock state in p9_req_put()[2],for p9_tag_remove() from p9_req_put() from IRQ context is usingspin_lock_irqsave() on "struct p9_client"->lock but trans_fd(not from IRQ context) is using spin_lock().Since the locks actually protect different things in client.c and intrans_fd.c, just replace trans_fd.c's lock by a new one specific to thetransport (client.c's protect the idr for fid/tag allocations,while trans_fd.c's protects its own req list and request status fieldthat acts as the transport's state machine)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49768 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:9p: trans_fd/p9_conn_cancel: drop client lock earliersyzbot reported a double-lock here and we no longer need thislock after requests have been moved off to local list:just drop the lock earlier.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49785 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/sgx: Add overflow check in sgx_validate_offset_length()sgx_validate_offset_length() function verifies "offset" and "length"arguments provided by userspace, but was missing an overflow check ontheir addition. Add it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49803 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: Fix memory leak of nsim_dev->fa_cookiekmemleak reports this issue:unreferenced object 0xffff8881bac872d0 (size 8): comm "sh", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcdThe issue occurs in the following scenarios:nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie..nsim_drv_remove()The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. Tofix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49806 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: microchip: sparx5: Fix potential null-ptr-deref in sparx_stats_init() and sparx5_start()sparx_stats_init() calls create_singlethread_workqueue() and notchecked the ret value, which may return NULL. And a null-ptr-deref mayhappen:sparx_stats_init() create_singlethread_workqueue() # failed, sparx5->stats_queue is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-derefCheck the ret value and return -ENOMEM if it is NULL. So assparx5_start().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49808 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: don't leak tagger-owned storage on switch driver unbindIn the initial commit dc452a471dba ("net: dsa: introduce tagger-ownedstorage for private and shared data"), we had a call totag_ops->disconnect(dst) issued from dsa_tree_free(), which is called attree teardown time.There were problems with connecting to a switch tree as a whole, so thisgot reworked to connecting to individual switches within the tree. Inthis process, tag_ops->disconnect(ds) was made to be called only fromswitch.c (cross-chip notifiers emitted as a result of dynamic tag protochanges), but the normal driver teardown code path wasn't replaced withanything.Solve this problem by adding a function that does the opposite ofdsa_switch_setup_tag_protocol(), which is called from the equivalentspot in dsa_switch_teardown(). The positioning here also ensures that wewon't have any use-after-free in tagging protocol (*rcv) ops, since theteardown sequence is as follows:dsa_tree_teardown-> dsa_tree_teardown_master -> dsa_master_teardown -> unsets master->dsa_ptr, making no further packets match the ETH_P_XDSA packet type handler-> dsa_tree_teardown_ports -> dsa_port_teardown -> dsa_slave_destroy -> unregisters DSA net devices, there is even a synchronize_net() in unregister_netdevice_many()-> dsa_tree_teardown_switches -> dsa_switch_teardown -> dsa_switch_teardown_tag_protocol -> finally frees the tagger-owned storage

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49828 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hugetlbfs: don't delete error page from pagecacheThis change is very similar to the change that was made for shmem [1], andit solves the same problem but for HugeTLBFS instead.Currently, when poison is found in a HugeTLB page, the page is removedfrom the page cache. That means that attempting to map or read thathugepage in the future will result in a new hugepage being allocatedinstead of notifying the user that the page was poisoned. As [1] states,this is effectively memory corruption.The fix is to leave the page in the page cache. If the user attempts touse a poisoned HugeTLB page with a syscall, the syscall will fail withEIO, the same error code that shmem uses. For attempts to map the page,the thread will get a BUS_MCEERR_AR SIGBUS.[1]: commit a76054266661 ("mm: shmem: don't truncate page if memory failure happens")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49831 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: initialize device's zone info for seedingWhen performing seeding on a zoned filesystem it is necessary toinitialize each zoned device's btrfs_zoned_device_info structure,otherwise mounting the filesystem will cause a NULL pointer dereference.This was uncovered by fstests' testcase btrfs/163.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49833 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: clone zoned device info when cloning a deviceWhen cloning a btrfs_device, we're not cloning the associatedbtrfs_zoned_device_info structure of the device in case of a zonedfilesystem.Later on this leads to a NULL pointer dereference when accessing thedevice's zone_info for instance when setting a zone as active.This was uncovered by fstests' testcase btrfs/161.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49840 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()We got a syzkaller problem because of aarch64 alignment faultif KFENCE enabled. When the size from user bpf program is an oddnumber, like 399, 407, etc, it will cause the struct skb_shared_info'sunaligned access. As seen below: BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213): __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline] bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381To fix the problem, we adjust @size so that (@size + @hearoom) is amultiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_infois aligned to a cache line.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfgipc_pcie_read_bios_cfg() is using the acpi_evaluate_dsm() toobtain the wwan power state configuration from BIOS but isnot freeing the acpi_object. The acpi_evaluate_dsm() returnedacpi_object to be freed.Free the acpi_object after use.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: marvell: prestera: fix memory leak in prestera_rxtx_switch_init()When prestera_sdma_switch_init() failed, the memory pointed to bysw->rxtx isn't released. Fix it. Only be compiled, not be tested.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49859 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: lapbether: fix issue of invalid opcode in lapbeth_open()If lapb_register() failed when lapb device goes to up for the first time,the NAPI is not disabled. As a result, the invalid opcode issue isreported when the lapb device goes to up for the second time.The stack info is as follows:[ 1958.311422][T11356] kernel BUG at net/core/dev.c:6442![ 1958.312206][T11356] invalid opcode: 0000 [#1] PREEMPT SMP KASAN[ 1958.315979][T11356] RIP: 0010:napi_enable+0x16a/0x1f0[ 1958.332310][T11356] Call Trace:[ 1958.332817][T11356] [ 1958.336135][T11356] lapbeth_open+0x18/0x90[ 1958.337446][T11356] __dev_open+0x258/0x490[ 1958.341672][T11356] __dev_change_flags+0x4d4/0x6a0[ 1958.345325][T11356] dev_change_flags+0x93/0x160[ 1958.346027][T11356] devinet_ioctl+0x1276/0x1bf0[ 1958.346738][T11356] inet_ioctl+0x1c8/0x2d0[ 1958.349638][T11356] sock_ioctl+0x5d1/0x750[ 1958.356059][T11356] __x64_sys_ioctl+0x3ec/0x1790[ 1958.365594][T11356] do_syscall_64+0x35/0x80[ 1958.366239][T11356] entry_SYSCALL_64_after_hwframe+0x46/0xb0[ 1958.377381][T11356]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49862 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_headerThis is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-valuein tipc_nl_compat_name_table_dump") where it should have type castedsizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negativevalue.syzbot reported a call trace because of it: BUG: KMSAN: uninit-value in ... tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934 __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238 tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321 tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] genl_family_rcv_msg net/netlink/genetlink.c:775 [inline] genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792 netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501 genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49867 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: wwan: iosm: fix memory leak in ipc_wwan_dellinkIOSM driver registers network device without setting theneeds_free_netdev flag, and does NOT call free_netdev() whenunregisters network device, which causes a memory leak.This patch sets needs_free_netdev to true when registersnetwork device, which makes netdev subsystem call free_netdev()automatically after unregister_netdevice().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49872 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: gso: fix panic on frag_list with mixed head alloc typesSince commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat whensplitting gso_size mangled skb having linear-headed frag_list"), it isallowed to change gso_size of a GRO packet. However, that commit assumesthat "checking the first list_skb member suffices; i.e if either of thelist_skb members have non head_frag head, then the first one has too".It turns out this assumption does not hold. We've seen BUG_ON being hitin skb_segment when skbs on the frag_list had differing head_frag withthe vmxnet3 driver. This happens because __netdev_alloc_skb and__napi_alloc_skb can return a skb that is page backed or kmalloceddepending on the requested size. As the result, the last small skb inthe GRO packet can be kmalloced.There are three different locations where this can be fixed:(1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem.(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the frag_list.(3) Walk the frag_list in skb_segment when determining whether NETIF_F_SG should be cleared. This of course slows things down.This patch implements (3). To limit the performance impact inskb_segment, the list is walked only for skbs with SKB_GSO_DODGY setthat have gso_size changed. Normal paths thus will not hit it.We could check only the last skb but since we need to walk the wholelist anyway, let's stay on the safe side.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49873 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix wrong reg type conversion in release_reference()Some helper functions will allocate memory. To avoid memory leaks, theverifier requires the eBPF program to release these memories by callingthe corresponding helper functions.When a resource is released, all pointer registers corresponding to theresource should be invalidated. The verifier use release_references() todo this job, by apply __mark_reg_unknown() to each relevant register.It will give these registers the type of SCALAR_VALUE. A register thatwill contain a pointer value at runtime, but of type SCALAR_VALUE, whichmay allow the unprivileged user to get a kernel pointer by storing thisregister into a map.Using __mark_reg_not_init() while NOT allow_ptr_leaks can mitigate thisproblem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49875 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILEWhen using bpftool to pin {PROG, MAP, LINK} without FILE,segmentation fault will occur. The reson is that the lackof FILE will cause strlen to trigger NULL pointer dereference.The corresponding stacktrace is shown below:do_pin do_pin_any do_pin_fd mount_bpffs_for_pin strlen(name) <- NULL pointer dereferenceFix it by adding validation to the common process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49878 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, verifier: Fix memory leak in array reallocation for stack stateIf an error (NULL) is returned by krealloc(), callers of realloc_array()were setting their allocation pointers to NULL, but on error krealloc()does not touch the original allocation. This would result in a memoryresource leak. Instead, free the old allocation on the error handlingpath.The memory leak information is as follows as also reported by Zhengchao: unreferenced object 0xffff888019801800 (size 256): comm "bpf_repo", pid 6490, jiffies 4294959200 (age 17.170s) 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 00 00 00 00 00 00 00 ................ backtrace: [<00000000b211474b>] __kmalloc_node_track_caller+0x45/0xc0 [<0000000086712a0b>] krealloc+0x83/0xd0 [<00000000139aab02>] realloc_array+0x82/0xe2 [<00000000b1ca41d1>] grow_stack_state+0xfb/0x186 [<00000000cd6f36d2>] check_mem_access.cold+0x141/0x1341 [<0000000081780455>] do_check_common+0x5358/0xb350 [<0000000015f6b091>] bpf_check.cold+0xc3/0x29d [<000000002973c690>] bpf_prog_load+0x13db/0x2240 [<00000000028d1644>] __sys_bpf+0x1605/0x4ce0 [<00000000053f29bd>] __x64_sys_bpf+0x75/0xb0 [<0000000056fedaf5>] do_syscall_64+0x35/0x80 [<000000002bd58261>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49898 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix tree mod log mishandling of reallocated nodesWe have been seeing the following panic in production kernel BUG at fs/btrfs/tree-mod-log.c:677! invalid opcode: 0000 [#1] SMP RIP: 0010:tree_mod_log_rewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001 R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00 FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: btrfs_get_old_root+0x12b/0x420 btrfs_search_old_slot+0x64/0x2f0 ? tree_mod_log_oldest_root+0x3d/0xf0 resolve_indirect_ref+0xfd/0x660 ? ulist_alloc+0x31/0x60 ? kmem_cache_alloc_trace+0x114/0x2c0 find_parent_nodes+0x97a/0x17e0 ? ulist_alloc+0x30/0x60 btrfs_find_all_roots_safe+0x97/0x150 iterate_extent_inodes+0x154/0x370 ? btrfs_search_path_in_tree+0x240/0x240 iterate_inodes_from_logical+0x98/0xd0 ? btrfs_search_path_in_tree+0x240/0x240 btrfs_ioctl_logical_to_ino+0xd9/0x180 btrfs_ioctl+0xe2/0x2ec0 ? __mod_memcg_lruvec_state+0x3d/0x280 ? do_sys_openat2+0x6d/0x140 ? kretprobe_dispatcher+0x47/0x70 ? kretprobe_rethook_handler+0x38/0x50 ? rethook_trampoline_handler+0x82/0x140 ? arch_rethook_trampoline_callback+0x3b/0x50 ? kmem_cache_free+0xfb/0x270 ? do_sys_openat2+0xd5/0x140 __x64_sys_ioctl+0x71/0xb0 do_syscall_64+0x2d/0x40Which is this code in tree_mod_log_rewind() switch (tm->op) { case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING: BUG_ON(tm->slot < n);This occurs because we replay the nodes in order that they happened, andwhen we do a REPLACE we will log a REMOVE_WHILE_FREEING for every slot,starting at 0. 'n' here is the number of items in this block, which inthis case was 1, but we had 2 REMOVE_WHILE_FREEING operations.The actual root cause of this was that we were replaying operations fora block that shouldn't have been replayed. Consider the followingsequence of events1. We have an already modified root, and we do a btrfs_get_tree_mod_seq().2. We begin removing items from this root, triggering KEY_REPLACE for it's child slots.3. We remove one of the 2 children this root node points to, thus triggering the root node promotion of the remaining child, and freeing this node.4. We modify a new root, and re-allocate the above node to the root node of this other root.The tree mod log looks something like this logical 0 op KEY_REPLACE (slot 1) seq 2 logical 0 op KEY_REMOVE (slot 1) seq 3 logical 0 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 4 logical 4096 op LOG_ROOT_REPLACE (old logical 0) seq 5 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 1) seq 6 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 7 logical 0 op LOG_ROOT_REPLACE (old logical 8192) seq 8>From here the bug is triggered by the following steps1. Call btrfs_get_old_root() on the new_root.2. We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is currently logical 0.3. tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which gives us the KEY_REPLACE seq 2, and since that's not a LOG_ROOT_REPLACE we incorrectly believe that we don't have an old root, because we expect that the most recent change should be a LOG_ROOT_REPLACE.4. Back in tree_mod_log_oldest_root() we don't have a LOG_ROOT_REPLACE, so we don't set old_root, we simply use our e---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fscrypt: stop using keyrings subsystem for fscrypt_master_keyThe approach of fs/crypto/ internally managing the fscrypt_master_keystructs as the payloads of "struct key" objects contained in a"struct key" keyring has outlived its usefulness. The original idea wasto simplify the code by reusing code from the keyrings subsystem.However, several issues have arisen that can't easily be resolved:- When a master key struct is destroyed, blk_crypto_evict_key() must be called on any per-mode keys embedded in it. (This started being the case when inline encryption support was added.) Yet, the keyrings subsystem can arbitrarily delay the destruction of keys, even past the time the filesystem was unmounted. Therefore, currently there is no easy way to call blk_crypto_evict_key() when a master key is destroyed. Currently, this is worked around by holding an extra reference to the filesystem's request_queue(s). But it was overlooked that the request_queue reference is *not* guaranteed to pin the corresponding blk_crypto_profile too; for device-mapper devices that support inline crypto, it doesn't. This can cause a use-after-free.- When the last inode that was using an incompletely-removed master key is evicted, the master key removal is completed by removing the key struct from the keyring. Currently this is done via key_invalidate(). Yet, key_invalidate() takes the key semaphore. This can deadlock when called from the shrinker, since in fscrypt_ioctl_add_key(), memory is allocated with GFP_KERNEL under the same semaphore.- More generally, the fact that the keyrings subsystem can arbitrarily delay the destruction of keys (via garbage collection delay, or via random processes getting temporary key references) is undesirable, as it means we can't strictly guarantee that all secrets are ever wiped.- Doing the master key lookups via the keyrings subsystem results in the key_permission LSM hook being called. fscrypt doesn't want this, as all access control for encrypted files is designed to happen via the files themselves, like any other files. The workaround which SELinux users are using is to change their SELinux policy to grant key search access to all domains. This works, but it is an odd extra step that shouldn't really have to be done.The fix for all these issues is to change the implementation to what Ishould have done originally: don't use the keyrings subsystem to keeptrack of the filesystem's fscrypt_master_key structs. Instead, juststore them in a regular kernel data structure, and rework the referencecounting, locking, and lifetime accordingly. Retain support forRCU-mode key lookups by using a hash table. Replace fscrypt_sb_free()with fscrypt_sb_delete(), which releases the keys synchronously and runsa bit earlier during unmount, so that block devices are still available.A side effect of this patch is that neither the master keys themselvesnor the filesystem keyrings will be listed in /proc/keys anymore.("Master key users" and the master key users keyrings will still belisted.) However, this was mostly an implementation detail, and it wasintended just for debugging purposes. I don't know of anyone using it.This patch does *not* change how "master key users" (->mk_users) works;that still uses the keyrings subsystem. That is still needed for keyquotas, and changing that isn't necessary to solve the issues listedabove. If we decide to change that too, it would be a separate patch.I've marked this as fixing the original commit that added the fscryptkeyring, but as noted above the most important issue that this patchfixes wasn't introduced until the addition of inline encryption support.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49901 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: Fix kmemleak in blk_mq_init_allocated_queueThere is a kmemleak caused by modprobe null_blk.kounreferenced object 0xffff8881acb1f000 (size 1024): comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [<000000004a10c249>] kmalloc_node_trace+0x22/0x60 [<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350 [<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0 [<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440 [<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0 [<00000000d10c98c3>] 0xffffffffc450d69d [<00000000b9299f48>] 0xffffffffc4538392 [<0000000061c39ed6>] do_one_initcall+0xd0/0x4f0 [<00000000b389383b>] do_init_module+0x1a4/0x680 [<0000000087cf3542>] load_module+0x6249/0x7110 [<00000000beba61b8>] __do_sys_finit_module+0x140/0x200 [<00000000fdcfff51>] do_syscall_64+0x35/0x80 [<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0That is because q->ma_ops is set to NULL before blk_release_queue iscalled.blk_mq_init_queue_data blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs for (i = 0; i < set->nr_hw_queues; i++) { old_hctx = xa_load(&q->hctx_table, i); if (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1] if (!old_hctx) break; xa_for_each_start(&q->hctx_table, j, hctx, j) blk_mq_exit_hctx(q, set, hctx, j); [2] if (!q->nr_hw_queues) [3] goto err_hctxs; err_exit: q->mq_ops = NULL; [4] blk_put_queue blk_release_queue if (queue_is_mq(q)) [5] blk_mq_release(q);[1]: blk_mq_alloc_and_init_hctx failed at i != 0.[2]: The hctxs allocated by [1] are moved to q->unused_hctx_list andwill be cleaned up in blk_mq_release.[3]: q->nr_hw_queues is 0.[4]: Set q->mq_ops to NULL.[5]: queue_is_mq returns false due to [4]. And blk_mq_releasewill not be called. The hctxs in q->unused_hctx_list are leaked.To fix it, call blk_release_queue in exception path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49903 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix WARNING in ip6_route_net_exit_late()During the initialization of ip6_route_net_init_late(), if fileipv6_route or rt6_stats fails to be created, the initialization issuccessful by default. Therefore, the ipv6_route or rt6_stats filedoesn't be found during the remove in ip6_route_net_exit_late(). Itwill cause WRNING.The following is the stack information:name 'rt6_stats'WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460Modules linked in:Workqueue: netns cleanup_netRIP: 0010:remove_proc_entry+0x389/0x460PKRU: 55555554Call Trace:ops_exit_list+0xb0/0x170cleanup_net+0x4ea/0xb00process_one_work+0x9bf/0x1710worker_thread+0x665/0x1080kthread+0x2e4/0x3a0ret_from_fork+0x1f/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49907 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mdio: fix undefined behavior in bit shift for __mdiobus_registerShifting signed 32-bit value by 31 bits is undefined, so changingsignificant bit to unsigned. The UBSAN warning calltrace like below:UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27left shift of 1 by 31 places cannot be represented in type 'int'Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c __mdiobus_register+0x49d/0x4e0 fixed_mdio_bus_init+0xd8/0x12d do_one_initcall+0x76/0x430 kernel_init_freeable+0x3b3/0x422 kernel_init+0x24/0x1e0 ret_from_fork+0x1f/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49911 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: enforce documented limit to prevent allocating huge memoryDaniel Xu reported that the hash:net,iface type of the ipset subsystem doesnot limit adding the same network with different interfaces to a set, whichcan lead to huge memory usage or allocation failure.The quick reproducer is$ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0$ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; doneThe backtrace when vmalloc fails: [Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages <...> [Tue Oct 25 00:13:08 2022] Call Trace: [Tue Oct 25 00:13:08 2022] [Tue Oct 25 00:13:08 2022] dump_stack_lvl+0x48/0x60 [Tue Oct 25 00:13:08 2022] warn_alloc+0x155/0x180 [Tue Oct 25 00:13:08 2022] __vmalloc_node_range+0x72a/0x760 [Tue Oct 25 00:13:08 2022] ? hash_netiface4_add+0x7c0/0xb20 [Tue Oct 25 00:13:08 2022] ? __kmalloc_large_node+0x4a/0x90 [Tue Oct 25 00:13:08 2022] kvmalloc_node+0xa6/0xd0 [Tue Oct 25 00:13:08 2022] ? hash_netiface4_resize+0x99/0x710 <...>The fix is to enforce the limit documented in the ipset(8) manpage:> The internal restriction of the hash:net,iface set type is that the same> network prefix cannot be stored with more than 64 different interfaces> in a single set.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49913 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix inode list leak during backref walking at find_parent_nodes()During backref walking, at find_parent_nodes(), if we are dealing with adata extent and we get an error while resolving the indirect backrefs, atresolve_indirect_refs(), or in the while loop that iterates over the refsin the direct refs rbtree, we end up leaking the inode lists attached tothe direct refs we have in the direct refs rbtree that were not yet addedto the refs ulist passed as argument to find_parent_nodes(). Since theywere not yet added to the refs ulist and prelim_release() does not freethe lists, on error the caller can only free the lists attached to therefs that were added to the refs ulist, all the remaining refs get theirinode lists never freed, therefore leaking their memory.Fix this by having prelim_release() always free any attached inode listto each ref found in the rbtree, and have find_parent_nodes() set theref's inode list to NULL once it transfers ownership of the inode listto a ref added to the refs ulist passed to find_parent_nodes().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49914 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix inode list leak during backref walking at resolve_indirect_refs()During backref walking, at resolve_indirect_refs(), if we get an errorwe jump to the 'out' label and call ulist_free() on the 'parents' ulist,which frees all the elements in the ulist - however that does not freeany inode lists that may be attached to elements, through the 'aux' fieldof a ulist node, so we end up leaking lists if we have any attached tothe unodes.Fix this by calling free_leaf_list() instead of ulist_free() when we exitfrom resolve_indirect_refs(). The static function free_leaf_list() ismoved up for this to be possible and it's slightly simplified by removingunnecessary code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49917 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix WARNING in ip_vs_app_net_cleanup()During the initialization of ip_vs_app_net_init(), if file ip_vs_appfails to be created, the initialization is successful by default.Therefore, the ip_vs_app file doesn't be found during the remove inip_vs_app_net_cleanup(). It will cause WRNING.The following is the stack information:name 'ip_vs_app'WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460Modules linked in:Workqueue: netns cleanup_netRIP: 0010:remove_proc_entry+0x389/0x460Call Trace:ops_exit_list+0x125/0x170cleanup_net+0x4ea/0xb00process_one_work+0x9bf/0x1710worker_thread+0x665/0x1080kthread+0x2e4/0x3a0ret_from_fork+0x1f/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49920 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: netlink notifier might race to release objectscommit release path is invoked via call_rcu and it runs lockless torelease the objects after rcu grace period. The netlink notifier handlermight win race to remove objects that the transaction context is stillreferencing from the commit release path.Call rcu_barrier() to ensure pending rcu callbacks run to completionif the list of transactions to be destroyed is not empty.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49921 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: Fix use after free in red_enqueue()We can't use "skb" again after passing it to qdisc_enqueue(). This isbasically identical to commit 2f09707d0c97 ("sch_sfb: Also store skblen before calling child enqueue").

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49926 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: Fix possible memory leaks in dsa_loop_init()kmemleak reported memory leaks in dsa_loop_init():kmemleak: 12 new suspected memory leaksunreferenced object 0xffff8880138ce000 (size 2048): comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s) backtrace: [<000000006a94f1d5>] kmalloc_trace+0x26/0x60 [<00000000a9c44622>] phy_device_create+0x5d/0x970 [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0 [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0 [<000000008a834798>] fixed_phy_register+0x84/0xb0 [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop] ...There are two reasons for memleak in dsa_loop_init().First, fixed_phy_register() create and register phy_device:fixed_phy_register() get_phy_device() phy_device_create() # freed by phy_device_free() phy_device_register() # freed by phy_device_remove()But fixed_phy_unregister() only calls phy_device_remove().So the memory allocated in phy_device_create() is leaked.Second, when mdio_driver_register() fail in dsa_loop_init(),it just returns and there is no cleanup for phydevs.Fix the problems by catching the error of mdio_driver_register()in dsa_loop_init(), then calling both fixed_phy_unregister() andphy_device_free() to release phydevs.Also add a function for phydevs cleanup to avoid duplacate.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49935 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf/dma-resv: check if the new fence is really laterPreviously when we added a fence to a dma_resv object we alwaysassumed the the newer than all the existing fences.With Jason's work to add an UAPI to explicit export/import that's notnecessary the case any more. So without this check we would allowuserspace to force the kernel into an use after free error.Since the change is very small and defensive it's probably a goodidea to backport this to stable kernels as well just in case othersare using the dma_resv object in the same way.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49967 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix a data-race around bpf_jit_limit.While reading bpf_jit_limit, it can be changed concurrently via sysctl,WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limitis long, so we need to add a paired READ_ONCE() to avoid load-tearing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49975 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Don't redirect packets with invalid pkt_lenSyzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout anyskbs, that is, the flow->head is null.The root cause, as the [2] says, is because that bpf_prog_test_run_skb()run a bpf prog which redirects empty skbs.So we should determine whether the length of the packet modified by bpfprog or others like bpf_prog_test is valid before forwarding it directly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49991 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: avoid corrupting page->mapping in hugetlb_mcopy_atomic_pteIn MCOPY_ATOMIC_CONTINUE case with a non-shared VMA, pages in the pagecache are installed in the ptes. But hugepage_add_new_anon_rmap is calledfor them mistakenly because they're not vm_shared. This will corrupt thepage->mapping used by page cache code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49994 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bootmem: remove the vmemmap pages from kmemleak in put_page_bootmemThe vmemmap pages is marked by kmemleak when allocated from memblock. Remove it from kmemleak when freeing the page. Otherwise, when we reusethe page, kmemleak may report such an error and then stop working. kmemleak: Cannot insert 0xffff98fb6eab3d40 into the object search tree (overlaps existing) kmemleak: Kernel memory leak detector disabled kmemleak: Object 0xffff98fb6be00000 (size 335544320): kmemleak: comm "swapper", pid 0, jiffies 4294892296 kmemleak: min_count = 0 kmemleak: count = 0 kmemleak: flags = 0x1 kmemleak: checksum = 0 kmemleak: backtrace:

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49997 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: lantiq_xrx200: restore buffer if memory allocation failedIn a situation where memory allocation fails, an invalid buffer addressis stored. When this descriptor is used again, the system panics in thebuild_skb() function when accessing memory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-49998 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix locking in rxrpc's sendmsgFix three bugs in the rxrpc's sendmsg implementation: (1) rxrpc_new_client_call() should release the socket lock when returning an error from rxrpc_get_call_slot(). (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex held in the event that we're interrupted by a signal whilst waiting for tx space on the socket or relocking the call mutex afterwards. Fix this by: (a) moving the unlock/lock of the call mutex up to rxrpc_send_data() such that the lock is not held around all of rxrpc_wait_for_tx_window*() and (b) indicating to higher callers whether we're return with the lock dropped. Note that this means recvmsg() will not block on this call whilst we're waiting. (3) After dropping and regaining the call mutex, rxrpc_send_data() needs to go and recheck the state of the tx_pending buffer and the tx_total_len check in case we raced with another sendmsg() on the same call.Thinking on this some more, it might make sense to have different locks forsendmsg() and recvmsg(). There's probably no need to make recvmsg() waitfor sendmsg(). It does mean that recvmsg() can return MSG_EOR indicatingthat a call is dead before a sendmsg() to that call returns - but that cancurrently happen anyway.Without fix (2), something like the following can be induced: WARNING: bad unlock balance detected! 5.16.0-rc6-syzkaller #0 Not tainted ------------------------------------- syz-executor011/3597 is trying to release lock (&call->user_mutex) at: [] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 but there are no more locks to release! other info that might help us debug this: no locks held by syz-executor011/3597. ... Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline] __lock_release kernel/locking/lockdep.c:5306 [inline] lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657 __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900 rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae[Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50000 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: fix stuck flows on cleanup due to pending workTo clear the flow table on flow table free, the following sequencenormally happens in order: 1) gc_step work is stopped to disable any further stats/del requests. 2) All flow table entries are set to teardown state. 3) Run gc_step which will queue HW del work for each flow table entry. 4) Waiting for the above del work to finish (flush). 5) Run gc_step again, deleting all entries from the flow table. 6) Flow table is freed.But if a flow table entry already has pending HW stats or HW add workstep 3 will not queue HW del work (it will be skipped), step 4 will waitfor the pending add/stats to finish, and step 5 will queue HW del workwhich might execute after freeing of the flow table.To fix the above, this patch flushes the pending work, then it sets theteardown flag to all flows in the flowtable and it forces a garbagecollector run to queue work to remove the flows from hardware, then itflushes this new pending work and (finally) it forces another garbagecollector run to remove the entry from the software flowtable.Stack trace:[47773.882335] BUG: KASAN: use-after-free in down_read+0x99/0x460[47773.883634] Write of size 8 at addr ffff888103b45aa8 by task kworker/u20:6/543704[47773.885634] CPU: 3 PID: 543704 Comm: kworker/u20:6 Not tainted 5.12.0-rc7+ #2[47773.886745] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)[47773.888438] Workqueue: nf_ft_offload_del flow_offload_work_handler [nf_flow_table][47773.889727] Call Trace:[47773.890214] dump_stack+0xbb/0x107[47773.890818] print_address_description.constprop.0+0x18/0x140[47773.892990] kasan_report.cold+0x7c/0xd8[47773.894459] kasan_check_range+0x145/0x1a0[47773.895174] down_read+0x99/0x460[47773.899706] nf_flow_offload_tuple+0x24f/0x3c0 [nf_flow_table][47773.907137] flow_offload_work_handler+0x72d/0xbe0 [nf_flow_table][47773.913372] process_one_work+0x8ac/0x14e0[47773.921325][47773.921325] Allocated by task 592159:[47773.922031] kasan_save_stack+0x1b/0x40[47773.922730] __kasan_kmalloc+0x7a/0x90[47773.923411] tcf_ct_flow_table_get+0x3cb/0x1230 [act_ct][47773.924363] tcf_ct_init+0x71c/0x1156 [act_ct][47773.925207] tcf_action_init_1+0x45b/0x700[47773.925987] tcf_action_init+0x453/0x6b0[47773.926692] tcf_exts_validate+0x3d0/0x600[47773.927419] fl_change+0x757/0x4a51 [cls_flower][47773.928227] tc_new_tfilter+0x89a/0x2070[47773.936652][47773.936652] Freed by task 543704:[47773.937303] kasan_save_stack+0x1b/0x40[47773.938039] kasan_set_track+0x1c/0x30[47773.938731] kasan_set_free_info+0x20/0x30[47773.939467] __kasan_slab_free+0xe7/0x120[47773.940194] slab_free_freelist_hook+0x86/0x190[47773.941038] kfree+0xce/0x3a0[47773.941644] tcf_ct_flow_table_cleanup_workOriginal patch description and stack trace by Paul Blakey.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50001 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_tproxy: restrict to prerouting hookTPROXY is only allowed from prerouting, but nft_tproxy doesn't check this.This fixes a crash (null dereference) when using tproxy from e.g. output.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: LAG, fix logic over MLX5_LAG_FLAG_NDEVS_READYOnly set MLX5_LAG_FLAG_NDEVS_READY if both netdevices are registered.Doing so guarantees that both ldev->pf[MLX5_LAG_P0].dev andldev->pf[MLX5_LAG_P1].dev have valid pointers whenMLX5_LAG_FLAG_NDEVS_READY is set.The core issue is asymmetry in setting MLX5_LAG_FLAG_NDEVS_READY andclearing it. Setting it is done wrongly when bothldev->pf[MLX5_LAG_P0].dev and ldev->pf[MLX5_LAG_P1].dev are set;clearing it is done right when either of ldev->pf[i].netdev is cleared.Consider the following scenario:1. PF0 loads and sets ldev->pf[MLX5_LAG_P0].dev to a valid pointer2. PF1 loads and sets both ldev->pf[MLX5_LAG_P1].dev and ldev->pf[MLX5_LAG_P1].netdev with valid pointers. This results in MLX5_LAG_FLAG_NDEVS_READY is set.3. PF0 is unloaded before setting dev->pf[MLX5_LAG_P0].netdev. MLX5_LAG_FLAG_NDEVS_READY remains set.Further execution of mlx5_do_bond() will result in null pointerdereference when calling mlx5_lag_is_multipath()This patch fixes the following call trace actually encountered:[ 1293.475195] BUG: kernel NULL pointer dereference, address: 00000000000009a8[ 1293.478756] #PF: supervisor read access in kernel mode[ 1293.481320] #PF: error_code(0x0000) - not-present page[ 1293.483686] PGD 0 P4D 0[ 1293.484434] Oops: 0000 [#1] SMP PTI[ 1293.485377] CPU: 1 PID: 23690 Comm: kworker/u16:2 Not tainted 5.18.0-rc5_for_upstream_min_debug_2022_05_05_10_13 #1[ 1293.488039] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 1293.490836] Workqueue: mlx5_lag mlx5_do_bond_work [mlx5_core][ 1293.492448] RIP: 0010:mlx5_lag_is_multipath+0x5/0x50 [mlx5_core][ 1293.494044] Code: e8 70 40 ff e0 48 8b 14 24 48 83 05 5c 1a 1b 00 01 e9 19 ff ff ff 48 83 05 47 1a 1b 00 01 eb d7 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 87 a8 09 00 00 48 85 c0 74 26 48 83 05 a7 1b 1b 00 01 41 b8[ 1293.498673] RSP: 0018:ffff88811b2fbe40 EFLAGS: 00010202[ 1293.500152] RAX: ffff88818a94e1c0 RBX: ffff888165eca6c0 RCX: 0000000000000000[ 1293.501841] RDX: 0000000000000001 RSI: ffff88818a94e1c0 RDI: 0000000000000000[ 1293.503585] RBP: 0000000000000000 R08: ffff888119886740 R09: ffff888165eca73c[ 1293.505286] R10: 0000000000000018 R11: 0000000000000018 R12: ffff88818a94e1c0[ 1293.506979] R13: ffff888112729800 R14: 0000000000000000 R15: ffff888112729858[ 1293.508753] FS: 0000000000000000(0000) GS:ffff88852cc40000(0000) knlGS:0000000000000000[ 1293.510782] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1293.512265] CR2: 00000000000009a8 CR3: 00000001032d4002 CR4: 0000000000370ea0[ 1293.514001] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 1293.515806] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50003 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: xsk: prohibit usage of non-balanced queue idFix the following scenario:1. ethtool -L $IFACE rx 8 tx 962. xdpsock -q 10 -t -zAbove refers to a case where user would like to attach XSK socket intxonly mode at a queue id that does not have a corresponding Rx queue.At this moment ice's XSK logic is tightly bound to act on a "queue pair",e.g. both Tx and Rx queues at a given queue id are disabled/enabled andboth of them will get XSK pool assigned, which is broken for the presentedqueue configuration. This results in the splat included at the bottom,which is basically an OOB access to Rx ring array.To fix this, allow using the ids only in scope of "combined" queuesreported by ethtool. However, logic should be rewritten to allow suchconfigurations later on, which would end up as a complete rewrite of thecontrol path, so let us go with this temporary fix.[420160.558008] BUG: kernel NULL pointer dereference, address: 0000000000000082[420160.566359] #PF: supervisor read access in kernel mode[420160.572657] #PF: error_code(0x0000) - not-present page[420160.579002] PGD 0 P4D 0[420160.582756] Oops: 0000 [#1] PREEMPT SMP NOPTI[420160.588396] CPU: 10 PID: 21232 Comm: xdpsock Tainted: G OE 5.19.0-rc7+ #10[420160.597893] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[420160.609894] RIP: 0010:ice_xsk_pool_setup+0x44/0x7d0 [ice][420160.616968] Code: f3 48 83 ec 40 48 8b 4f 20 48 8b 3f 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 8d 04 ed 00 00 00 00 48 01 c1 48 8b 11 <0f> b7 92 82 00 00 00 48 85 d2 0f 84 2d 75 00 00 48 8d 72 ff 48 85[420160.639421] RSP: 0018:ffffc9002d2afd48 EFLAGS: 00010282[420160.646650] RAX: 0000000000000050 RBX: ffff88811d8bdd00 RCX: ffff888112c14ff8[420160.655893] RDX: 0000000000000000 RSI: ffff88811d8bdd00 RDI: ffff888109861000[420160.665166] RBP: 000000000000000a R08: 000000000000000a R09: 0000000000000000[420160.674493] R10: 000000000000889f R11: 0000000000000000 R12: 000000000000000a[420160.683833] R13: 000000000000000a R14: 0000000000000000 R15: ffff888117611828[420160.693211] FS: 00007fa869fc1f80(0000) GS:ffff8897e0880000(0000) knlGS:0000000000000000[420160.703645] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[420160.711783] CR2: 0000000000000082 CR3: 00000001d076c001 CR4: 00000000007706e0[420160.721399] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[420160.731045] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[420160.740707] PKRU: 55555554[420160.745960] Call Trace:[420160.750962] [420160.755597] ? kmalloc_large_node+0x79/0x90[420160.762703] ? __kmalloc_node+0x3f5/0x4b0[420160.769341] xp_assign_dev+0xfd/0x210[420160.775661] ? shmem_file_read_iter+0x29a/0x420[420160.782896] xsk_bind+0x152/0x490[420160.788943] __sys_bind+0xd0/0x100[420160.795097] ? exit_to_user_mode_prepare+0x20/0x120[420160.802801] __x64_sys_bind+0x16/0x20[420160.809298] do_syscall_64+0x38/0x90[420160.815741] entry_SYSCALL_64_after_hwframe+0x63/0xcd[420160.823731] RIP: 0033:0x7fa86a0dd2fb[420160.830264] Code: c3 66 0f 1f 44 00 00 48 8b 15 69 8b 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bc 0f 1f 44 00 00 f3 0f 1e fa b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 8b 0c 00 f7 d8 64 89 01 48[420160.855410] RSP: 002b:00007ffc1146f618 EFLAGS: 00000246 ORIG_RAX: 0000000000000031[420160.866366] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa86a0dd2fb[420160.876957] RDX: 0000000000000010 RSI: 00007ffc1146f680 RDI: 0000000000000003[420160.887604] RBP: 000055d7113a0520 R08: 00007fa868fb8000 R09: 0000000080000000[420160.898293] R10: 0000000000008001 R11: 0000000000000246 R12: 000055d7113a04e0[420160.909038] R13: 000055d7113a0320 R14: 000000000000000a R15: 0000000000000000[420160.919817] [420160.925659] Modules linked in: ice(OE) af_packet binfmt_misc---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50007 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: fix refcount leak in __xfrm_policy_check()The issue happens on an error path in __xfrm_policy_check(). When thefetching process of the object `pols[1]` fails, the function simplyreturns 0, forgetting to decrement the reference count of `pols[0]`,which is incremented earlier by either xfrm_sk_policy_lookup() orxfrm_policy_lookup(). This may result in memory leaks.Fix it by decreasing the reference count of `pols[0]` in that path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50015 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda-ipc: Do not process IPC reply before firmware bootIt is not yet clear, but it is possible to create a firmware so brokenthat it will send a reply message before a FW_READY message (it is notyet clear if FW_READY will arrive later).Since the reply_data is allocated only after the FW_READY message, thiswill lead to a NULL pointer dereference if not filtered out.The issue was reported with IPC4 firmware but the same condition is presentfor IPC3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50016 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: cnl: Do not process IPC reply before firmware bootIt is not yet clear, but it is possible to create a firmware so brokenthat it will send a reply message before a FW_READY message (it is notyet clear if FW_READY will arrive later).Since the reply_data is allocated only after the FW_READY message, thiswill lead to a NULL pointer dereference if not filtered out.The issue was reported with IPC4 firmware but the same condition is presentfor IPC3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50042 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: genl: fix error path memory leak in policy dumpingIf construction of the array of policies fails when recordingnon-first policy we need to unwind.netlink_policy_dump_add_policy() itself also needs fixing asit currently gives up on error without recording the allocatedpointer in the pstate pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50043 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix potential refcount leak in ndisc_router_discovery()The issue happens on specific paths in the function. After both theobject `rt` and `neigh` are grabbed successfully, when `lifetime` isnonzero but the metric needs change, the function just deletes theroute and set `rt` to NULL. Then, it may try grabbing `rt` and `neigh`again if above conditions hold. The function simply overwrite `neigh`if succeeds or returns if fails, without decreasing the referencecount of previous `neigh`. This may result in memory leaks.Fix it by decrementing the reference count of `neigh` in place.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50044 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: start MHI channel after endpoit creationMHI channel may generates event/interrupt right after enabling.It may leads to 2 race conditions issues.1)Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check: if (!qdev || mhi_res->transaction_status) return;Because dev_set_drvdata(&mhi_dev->dev, qdev) may be not performed atthis moment. In this situation qrtr-ns will be unable to enumerateservices in device.---------------------------------------------------------------2)Such event may come at the moment after dev_set_drvdata() andbefore qrtr_endpoint_register(). In this case kernel will panic withaccessing wrong pointer at qcom_mhi_qrtr_dl_callback(): rc = qrtr_endpoint_post(&qdev->ep, mhi_res->buf_addr, mhi_res->bytes_xferd);Because endpoint is not created yet.--------------------------------------------------------------So move mhi_prepare_for_transfer_autoqueue after endpoint creationto fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50048 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: possible module reference underflow in error pathdst->ops is set on when nft_expr_clone() fails, but module refcount hasnot been bumped yet, therefore nft_expr_destroy() leads to modulereference underflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50050 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()snprintf() returns the would-be-filled size when the string overflowsthe given buffer size, hence using this value may result in the bufferoverflow (although it's unrealistic).This patch replaces with a safer version, scnprintf() for paperingover such a potential issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:BPF: Fix potential bad pointer dereference in bpf_sys_bpf()The bpf_sys_bpf() helper function allows an eBPF program to load anothereBPF program from within the kernel. In this case the argument unionbpf_attr pointer (as well as the insns and license pointers inside) is akernel address instead of a userspace address (which is the case of ausual bpf() syscall). To make the memory copying process in the syscallwork in both cases, bpfptr_t was introduced to wrap around the pointerand distinguish its origin. Specifically, when copying memory contentsfrom a bpfptr_t, a copy_from_user() is performed in case of a userspaceaddress and a memcpy() is performed for a kernel address.This can lead to problems because the in-kernel pointer is never checkedfor validity. The problem happens when an eBPF syscall program tries tocall bpf_sys_bpf() to load a program but provides a bad insns pointer --say 0xdeadbeef -- in the bpf_attr union. The helper calls __sys_bpf()which would then call bpf_prog_load() to load the program.bpf_prog_load() is responsible for copying the eBPF instructions to thenewly allocated memory for the program; it creates a kernel bpfptr_t forinsns and invokes copy_from_bpfptr(). Internally, all bpfptr_toperations are backed by the corresponding sockptr_t operations, whichperforms direct memcpy() on kernel pointers for copy_from/strncpy_fromoperations. Therefore, the code is always happy to dereference the badpointer to trigger a un-handle-able page fault and in turn an oops.However, this is not supposed to happen because at that point the eBPFprogram is already verified and should not cause a memory error.Sample KASAN trace:[ 25.685056][ T228] ==================================================================[ 25.685680][ T228] BUG: KASAN: user-memory-access in copy_from_bpfptr+0x21/0x30[ 25.686210][ T228] Read of size 80 at addr 00000000deadbeef by task poc/228[ 25.686732][ T228][ 25.686893][ T228] CPU: 3 PID: 228 Comm: poc Not tainted 5.19.0-rc7 #7[ 25.687375][ T228] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014[ 25.687991][ T228] Call Trace:[ 25.688223][ T228] [ 25.688429][ T228] dump_stack_lvl+0x73/0x9e[ 25.688747][ T228] print_report+0xea/0x200[ 25.689061][ T228] ? copy_from_bpfptr+0x21/0x30[ 25.689401][ T228] ? _printk+0x54/0x6e[ 25.689693][ T228] ? _raw_spin_lock_irqsave+0x70/0xd0[ 25.690071][ T228] ? copy_from_bpfptr+0x21/0x30[ 25.690412][ T228] kasan_report+0xb5/0xe0[ 25.690716][ T228] ? copy_from_bpfptr+0x21/0x30[ 25.691059][ T228] kasan_check_range+0x2bd/0x2e0[ 25.691405][ T228] ? copy_from_bpfptr+0x21/0x30[ 25.691734][ T228] memcpy+0x25/0x60[ 25.692000][ T228] copy_from_bpfptr+0x21/0x30[ 25.692328][ T228] bpf_prog_load+0x604/0x9e0[ 25.692653][ T228] ? cap_capable+0xb4/0xe0[ 25.692956][ T228] ? security_capable+0x4f/0x70[ 25.693324][ T228] __sys_bpf+0x3af/0x580[ 25.693635][ T228] bpf_sys_bpf+0x45/0x240[ 25.693937][ T228] bpf_prog_f0ec79a5a3caca46_bpf_func1+0xa2/0xbd[ 25.694394][ T228] bpf_prog_run_pin_on_cpu+0x2f/0xb0[ 25.694756][ T228] bpf_prog_test_run_syscall+0x146/0x1c0[ 25.695144][ T228] bpf_prog_test_run+0x172/0x190[ 25.695487][ T228] __sys_bpf+0x2c5/0x580[ 25.695776][ T228] __x64_sys_bpf+0x3a/0x50[ 25.696084][ T228] do_syscall_64+0x60/0x90[ 25.696393][ T228] ? fpregs_assert_state_consistent+0x50/0x60[ 25.696815][ T228] ? exit_to_user_mode_prepare+0x36/0xa0[ 25.697202][ T228] ? syscall_exit_to_user_mode+0x20/0x40[ 25.697586][ T228] ? do_syscall_64+0x6e/0x90[ 25.697899][ T228] entry_SYSCALL_64_after_hwframe+0x63/0xcd[ 25.698312][ T228] RIP: 0033:0x7f6d543fb759[ 25.698624][ T228] Code: 08 5b 89 e8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50070 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: do not queue data on closed subflowsDipanjan reported a syzbot splat at close time:WARNING: CPU: 1 PID: 10818 at net/ipv4/af_inet.c:153inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153Modules linked in: uio_ivshmem(OE) uio(E)CPU: 1 PID: 10818 Comm: kworker/1:16 Tainted: G OE5.19.0-rc6-g2eae0556bb9d #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.13.0-1ubuntu1.1 04/01/2014Workqueue: events mptcp_workerRIP: 0010:inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153Code: 21 02 00 00 41 8b 9c 24 28 02 00 00 e9 07 ff ff ff e8 34 4d 91f9 89 ee 4c 89 e7 e8 4a 47 60 ff e9 a6 fc ff ff e8 20 4d 91 f9 <0f> 0be9 84 fe ff ff e8 14 4d 91 f9 0f 0b e9 d4 fd ff ff e8 08 4dRSP: 0018:ffffc9001b35fa78 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000002879d0 RCX: ffff8881326f3b00RDX: 0000000000000000 RSI: ffff8881326f3b00 RDI: 0000000000000002RBP: ffff888179662674 R08: ffffffff87e983a0 R09: 0000000000000000R10: 0000000000000005 R11: 00000000000004ea R12: ffff888179662400R13: ffff888179662428 R14: 0000000000000001 R15: ffff88817e38e258FS: 0000000000000000(0000) GS:ffff8881f5f00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020007bc0 CR3: 0000000179592000 CR4: 0000000000150ee0Call Trace: __sk_destruct+0x4f/0x8e0 net/core/sock.c:2067 sk_destruct+0xbd/0xe0 net/core/sock.c:2112 __sk_free+0xef/0x3d0 net/core/sock.c:2123 sk_free+0x78/0xa0 net/core/sock.c:2134 sock_put include/net/sock.h:1927 [inline] __mptcp_close_ssk+0x50f/0x780 net/mptcp/protocol.c:2351 __mptcp_destroy_sock+0x332/0x760 net/mptcp/protocol.c:2828 mptcp_worker+0x5d2/0xc90 net/mptcp/protocol.c:2586 process_one_work+0x9cc/0x1650 kernel/workqueue.c:2289 worker_thread+0x623/0x1070 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 The root cause of the problem is that an mptcp-level (re)transmit canrace with mptcp_close() and the packet scheduler checks the subflowstate before acquiring the socket lock: we can try to (re)transmit onan already closed ssk.Fix the issue checking again the subflow socket status under thesubflow socket lock protection. Additionally add the missing checkfor the fallback-to-tcp case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50071 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: move subflow cleanup in mptcp_destroy_common()If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATEeBPF program, the MPTCP protocol ends-up leaking all the subflows:the related cleanup happens in __mptcp_destroy_sock() that is notinvoked in such code path.Address the issue moving the subflow sockets cleanup in themptcp_destroy_common() helper, which is invoked in every msk cleanuppath.Additionally get rid of the intermediate list_splice_init step, whichis an unneeded relic from the past.The issue is present since before the reported root cause commit, butany attempt to backport the fix before that hash will require a completerewrite.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50080 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tee: add overflow check in register_shm_helper()With special lengths supplied by user space, register_shm_helper() hasan integer overflow when calculating the number of pages covered by asupplied user space memory region.This causes internal_get_user_pages_fast() a helper function ofpin_user_pages_fast() to do a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Modules linked in: CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pc : internal_get_user_pages_fast+0x474/0xa80 Call trace: internal_get_user_pages_fast+0x474/0xa80 pin_user_pages_fast+0x24/0x4c register_shm_helper+0x194/0x330 tee_shm_register_user_buf+0x78/0x120 tee_ioctl+0xd0/0x11a0 __arm64_sys_ioctl+0xa8/0xec invoke_syscall+0x48/0x114Fix this by adding an an explicit call to access_ok() intee_shm_register_user_buf() to catch an invalid user space addressearly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50082 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix warning in ext4_iomap_begin as race between bmap and writeWe got issue as follows:------------[ cut here ]------------WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0RIP: 0010:ext4_iomap_begin+0x182/0x5d0RSP: 0018:ffff88812460fa08 EFLAGS: 00010293RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20fR10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691eeFS: 00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: iomap_apply+0x119/0x570 iomap_bmap+0x124/0x150 ext4_bmap+0x14f/0x250 bmap+0x55/0x80 do_vfs_ioctl+0x952/0xbd0 __x64_sys_ioctl+0xc6/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9Above issue may happen as follows: bmap writebmap ext4_bmap iomap_bmap ext4_iomap_begin ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin ext4_prepare_inline_data ext4_create_inline_data ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_onTo solved above issue hold inode lock in ext4_bamp.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50086 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: don't allow the same type rq_qos add more than onceIn our test of iocost, we encountered some list add/del corruptions ofinner_walk list in ioc_timer_fn.The reason can be described as follows:cpu 0 cpu 1ioc_qos_write ioc_qos_writeioc = q_to_ioc(queue);if (!ioc) { ioc = kzalloc(); ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ... rq_qos_add(q, rqos); } ... rq_qos_add(q, rqos); ...}When the io.cost.qos file is written by two cpus concurrently, rq_qos maybe added to one disk twice. In that case, there will be two iocs enabledand running on one disk. They own different iocgs on their active list. Inthe ioc_timer_fn function, because of the iocgs from two iocs have thesame root iocg, the root iocg's walk_list may be overwritten by each otherand this leads to list add/del corruptions in building or destroying theinner_walk list.And so far, the blk-rq-qos framework works in case that one instance forone type rq_qos per queue by default. This patch make this explicit andalso fix the crash above.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50089 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: ensure pages are unlocked on cow_file_range() failureThere is a hung_task report on zoned btrfs like below.https://github.com/naota/linux/issues/59 [726.328648] INFO: task rocksdb:high0:11085 blocked for more than 241 seconds. [726.329839] Not tainted 5.16.0-rc1+ #1 [726.330484] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [726.331603] task:rocksdb:high0 state:D stack: 0 pid:11085 ppid: 11082 flags:0x00000000 [726.331608] Call Trace: [726.331611] [726.331614] __schedule+0x2e5/0x9d0 [726.331622] schedule+0x58/0xd0 [726.331626] io_schedule+0x3f/0x70 [726.331629] __folio_lock+0x125/0x200 [726.331634] ? find_get_entries+0x1bc/0x240 [726.331638] ? filemap_invalidate_unlock_two+0x40/0x40 [726.331642] truncate_inode_pages_range+0x5b2/0x770 [726.331649] truncate_inode_pages_final+0x44/0x50 [726.331653] btrfs_evict_inode+0x67/0x480 [726.331658] evict+0xd0/0x180 [726.331661] iput+0x13f/0x200 [726.331664] do_unlinkat+0x1c0/0x2b0 [726.331668] __x64_sys_unlink+0x23/0x30 [726.331670] do_syscall_64+0x3b/0xc0 [726.331674] entry_SYSCALL_64_after_hwframe+0x44/0xae [726.331677] RIP: 0033:0x7fb9490a171b [726.331681] RSP: 002b:00007fb943ffac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000057 [726.331684] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9490a171b [726.331686] RDX: 00007fb943ffb040 RSI: 000055a6bbe6ec20 RDI: 00007fb94400d300 [726.331687] RBP: 00007fb943ffad00 R08: 0000000000000000 R09: 0000000000000000 [726.331688] R10: 0000000000000031 R11: 0000000000000246 R12: 00007fb943ffb000 [726.331690] R13: 00007fb943ffb040 R14: 0000000000000000 R15: 00007fb943ffd260 [726.331693] While we debug the issue, we found running fstests generic/551 on 5GBnon-zoned null_blk device in the emulated zoned mode also had asimilar hung issue.Also, we can reproduce the same symptom with an error injectedcow_file_range() setup.The hang occurs when cow_file_range() fails in the middle ofallocation. cow_file_range() called from do_allocation_zoned() cansplit the give region ([start, end]) for allocation depending oncurrent block group usages. When btrfs can allocate bytes for one partof the split regions but fails for the other region (e.g. because of-ENOSPC), we return the error leaving the pages in the succeeded regionslocked. Technically, this occurs only when @unlock == 0. Otherwise, weunlock the pages in an allocated region after creating an orderedextent.Considering the callers of cow_file_range(unlock=0) won't write outthe pages, we can unlock the pages on error exit fromcow_file_range(). So, we can ensure all the pages except @locked_pageare unlocked on error case.In summary, cow_file_range now behaves like this:- page_started == 1 (return value) - All the pages are unlocked. IO is started.- unlock == 1 - All the pages except @locked_page are unlocked in any case- unlock == 0 - On success, all the pages are locked for writing out them - On failure, all the pages except @locked_page are unlocked

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: replace BTRFS_MAX_EXTENT_SIZE with fs_info->max_extent_sizeOn zoned filesystem, data write out is limited by max_zone_append_size,and a large ordered extent is split according the size of a bio. OTOH,the number of extents to be written is calculated usingBTRFS_MAX_EXTENT_SIZE, and that estimated number is used to reserve themetadata bytes to update and/or create the metadata items.The metadata reservation is done at e.g, btrfs_buffered_write() and thenreleased according to the estimation changes. Thus, if the number of extentincreases massively, the reserved metadata can run out.The increase of the number of extents easily occurs on zoned filesystemif BTRFS_MAX_EXTENT_SIZE > max_zone_append_size. And, it causes thefollowing warning on a small RAM environment with disabling metadataover-commit (in the following patch).[75721.498492] ------------[ cut here ]------------[75721.505624] BTRFS: block rsv 1 returned -28[75721.512230] WARNING: CPU: 24 PID: 2327559 at fs/btrfs/block-rsv.c:537 btrfs_use_block_rsv+0x560/0x760 [btrfs][75721.581854] CPU: 24 PID: 2327559 Comm: kworker/u64:10 Kdump: loaded Tainted: G W 5.18.0-rc2-BTRFS-ZNS+ #109[75721.597200] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021[75721.607310] Workqueue: btrfs-endio-write btrfs_work_helper [btrfs][75721.616209] RIP: 0010:btrfs_use_block_rsv+0x560/0x760 [btrfs][75721.646649] RSP: 0018:ffffc9000fbdf3e0 EFLAGS: 00010286[75721.654126] RAX: 0000000000000000 RBX: 0000000000004000 RCX: 0000000000000000[75721.663524] RDX: 0000000000000004 RSI: 0000000000000008 RDI: fffff52001f7be6e[75721.672921] RBP: ffffc9000fbdf420 R08: 0000000000000001 R09: ffff889f8d1fc6c7[75721.682493] R10: ffffed13f1a3f8d8 R11: 0000000000000001 R12: ffff88980a3c0e28[75721.692284] R13: ffff889b66590000 R14: ffff88980a3c0e40 R15: ffff88980a3c0e8a[75721.701878] FS: 0000000000000000(0000) GS:ffff889f8d000000(0000) knlGS:0000000000000000[75721.712601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[75721.720726] CR2: 000055d12e05c018 CR3: 0000800193594000 CR4: 0000000000350ee0[75721.730499] Call Trace:[75721.735166] [75721.739886] btrfs_alloc_tree_block+0x1e1/0x1100 [btrfs][75721.747545] ? btrfs_alloc_logged_file_extent+0x550/0x550 [btrfs][75721.756145] ? btrfs_get_32+0xea/0x2d0 [btrfs][75721.762852] ? btrfs_get_32+0xea/0x2d0 [btrfs][75721.769520] ? push_leaf_left+0x420/0x620 [btrfs][75721.776431] ? memcpy+0x4e/0x60[75721.781931] split_leaf+0x433/0x12d0 [btrfs][75721.788392] ? btrfs_get_token_32+0x580/0x580 [btrfs][75721.795636] ? push_for_double_split.isra.0+0x420/0x420 [btrfs][75721.803759] ? leaf_space_used+0x15d/0x1a0 [btrfs][75721.811156] btrfs_search_slot+0x1bc3/0x2790 [btrfs][75721.818300] ? lock_downgrade+0x7c0/0x7c0[75721.824411] ? free_extent_buffer.part.0+0x107/0x200 [btrfs][75721.832456] ? split_leaf+0x12d0/0x12d0 [btrfs][75721.839149] ? free_extent_buffer.part.0+0x14f/0x200 [btrfs][75721.846945] ? free_extent_buffer+0x13/0x20 [btrfs][75721.853960] ? btrfs_release_path+0x4b/0x190 [btrfs][75721.861429] btrfs_csum_file_blocks+0x85c/0x1500 [btrfs][75721.869313] ? rcu_read_lock_sched_held+0x16/0x80[75721.876085] ? lock_release+0x552/0xf80[75721.881957] ? btrfs_del_csums+0x8c0/0x8c0 [btrfs][75721.888886] ? __kasan_check_write+0x14/0x20[75721.895152] ? do_raw_read_unlock+0x44/0x80[75721.901323] ? _raw_write_lock_irq+0x60/0x80[75721.907983] ? btrfs_global_root+0xb9/0xe0 [btrfs][75721.915166] ? btrfs_csum_root+0x12b/0x180 [btrfs][75721.921918] ? btrfs_get_global_root+0x820/0x820 [btrfs][75721.929166] ? _raw_write_unlock+0x23/0x40[75721.935116] ? unpin_extent_cache+0x1e3/0x390 [btrfs][75721.942041] btrfs_finish_ordered_io.isra.0+0xa0c/0x1dc0 [btrfs][75721.949906] ? try_to_wake_up+0x30/0x14a0[75721.955700] ? btrfs_unlink_subvol+0xda0/0xda0 [btrfs][75721.962661] ? rcu---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50091 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:locking/csd_lock: Change csdlock_debug from early_param to __setupThe csdlock_debug kernel-boot parameter is parsed by theearly_param() function csdlock_debug(). If set, csdlock_debug()invokes static_branch_enable() to enable csd_lock_wait feature, whichtriggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y andCONFIG_SPARSEMEM_VMEMMAP=n.With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called instatic_key_enable() and returns NULL, resulting in a NULL dereferencebecause mem_section is initialized only later in sparse_init().This is also a problem for powerpc because early_param() functionsare invoked earlier than jump_label_init(), also resulting instatic_key_enable() failures. These failures cause the warning "statickey 'xxx' used before call to jump_label_init()".Thus, early_param is too early for csd_lock_wait to runstatic_branch_enable(), so changes it to __setup to fix these.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50096 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/kprobes: Update kcb status flag after singlesteppingFix kprobes to update kcb (kprobes control block) status flag toKPROBE_HIT_SSDONE even if the kp->post_handler is not set.This bug may cause a kernel panic if another INT3 user runs rightafter kprobes because kprobe_int3_handler() misunderstands theINT3 is kprobe's single stepping INT3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50114 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: 9p: fix refcount leak in p9_read_work() error handlingp9_req_put need to be called when m->rreq->rc.sdata is NULL to avoidtemporary refcount leak.[Dominique: commit wording adjustments, p9_req_put argument fixes for rebase]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50144 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soundwire: revisit driver bind/unbind and callbacksIn the SoundWire probe, we store a pointer from the driver ops intothe 'slave' structure. This can lead to kernel oopses when unbindingcodec drivers, e.g. with the following sequence to remove machinedriver and codec driver./sbin/modprobe -r snd_soc_sof_sdw/sbin/modprobe -r snd_soc_rt711The full details can be found in the BugLink below, for reference thetwo following examples show different cases of driver ops/callbacksbeing invoked after the driver .remove().kernel: BUG: kernel NULL pointer dereference, address: 0000000000000150kernel: Workqueue: events cdns_update_slave_status_work [soundwire_cadence]kernel: RIP: 0010:mutex_lock+0x19/0x30kernel: Call Trace:kernel: ? sdw_handle_slave_status+0x426/0xe00 [soundwire_bus 94ff184bf398570c3f8ff7efe9e32529f532e4ae]kernel: ? newidle_balance+0x26a/0x400kernel: ? cdns_update_slave_status_work+0x1e9/0x200 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82]kernel: BUG: unable to handle page fault for address: ffffffffc07654c8kernel: Workqueue: pm pm_runtime_workkernel: RIP: 0010:sdw_bus_prep_clk_stop+0x6f/0x160 [soundwire_bus]kernel: Call Trace:kernel: kernel: sdw_cdns_clock_stop+0xb5/0x1b0 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82]kernel: intel_suspend_runtime+0x5f/0x120 [soundwire_intel aca858f7c87048d3152a4a41bb68abb9b663a1dd]kernel: ? dpm_sysfs_remove+0x60/0x60This was not detected earlier in Intel tests since the tests firstremove the parent PCI device and shut down the bus. The sequenceabove is a corner case which keeps the bus operational but without adriver bound.While trying to solve this kernel oopses, it became clear that theexisting SoundWire bus does not deal well with the unbind case.Commit 528be501b7d4a ("soundwire: sdw_slave: add probe_complete structure and new fields")added a 'probed' status variable and a 'probe_complete'struct completion. This status is however not reset on remove andlikewise the 'probe complete' is not re-initialized, so thebind/unbind/bind test cases would fail. The timeout used before the'update_status' callback was also a bad idea in hindsight, thereshould really be no timing assumption as to if and when a driver isbound to a device.An initial draft was based on device_lock() and device_unlock() wastested. This proved too complicated, with deadlocks created during thesuspend-resume sequences, which also use the same device_lock/unlock()as the bind/unbind sequences. On a CometLake device, a bad DSDT/BIOScaused spurious resumes and the use of device_lock() caused hangsduring suspend. After multiple weeks or testing and painfulreverse-engineering of deadlocks on different devices, we looked foralternatives that did not interfere with the device core.A bus notifier was used successfully to keep track of DRIVER_BOUND andDRIVER_UNBIND events. This solved the bind-unbind-bind case in tests,but it can still be defeated with a theoretical corner case where thememory is freed by a .remove while the callback is in use. Thenotifier only helps make sure the driver callbacks are valid, but notthat the memory allocated in probe remains valid while the callbacksare invoked.This patch suggests the introduction of a new 'sdw_dev_lock' mutexprotecting probe/remove and all driver callbacks. Since this mutex is'local' to SoundWire only, it does not interfere with existing locksand does not create deadlocks. In addition, this patch removes the'probe_complete' completion, instead we directly invoke the'update_status' from the probe routine. That removes any sort oftiming dependency and a much better support for the device/drivermodel, the driver could be bound before the bus started, or eons afterthe bus started and the hardware would be properly initialized in allcases.BugLink: https://github.com/thesofproject/linux/is---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50159 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:of: check previous kernel's ima-kexec-buffer against memory boundsPresently ima_get_kexec_buffer() doesn't check if the previous kernel'sima-kexec-buffer lies outside the addressable memory range. This can resultin a kernel panic if the new kernel is booted with 'mem=X' arg and theima-kexec-buffer was allocated beyond that range by the previous kernel.The panic is usually of the form below:$ sudo kexec --initrd initrd vmlinux --append='mem=16G' BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000 Faulting instruction address: 0xc000000000837974 Oops: Kernel access of bad area, sig: 11 [#1] NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 Call Trace: [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330 7c0802a6 fb610198 7c9b2378 f80101d0 2c090001 40820614 e9240010 ---[ end trace 0000000000000000 ]---Fix this issue by checking returned PFN range of previous kernel'sima-kexec-buffer with page_is_ram() to ensure correct memory bounds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50163 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: fix incorrect dev_tracker usageWhile investigating a separate rose issue [1], and enablingCONFIG_NET_DEV_REFCNT_TRACKER=y, Bernard reported an orthogonal ax25 issue [2]An ax25_dev can be used by one (or many) struct ax25_cb.We thus need different dev_tracker, one per struct ax25_cb.After this patch is applied, we are able to focus on rose.[1] https://lore.kernel.org/netdev/fb7544a1-f42e-9254-18cc-c9b071f4ca70@free.fr/[2][ 205.798723] reference already released.[ 205.798732] allocated in:[ 205.798734] ax25_bind+0x1a2/0x230 [ax25][ 205.798747] __sys_bind+0xea/0x110[ 205.798753] __x64_sys_bind+0x18/0x20[ 205.798758] do_syscall_64+0x5c/0x80[ 205.798763] entry_SYSCALL_64_after_hwframe+0x44/0xae[ 205.798768] freed in:[ 205.798770] ax25_release+0x115/0x370 [ax25][ 205.798778] __sock_release+0x42/0xb0[ 205.798782] sock_close+0x15/0x20[ 205.798785] __fput+0x9f/0x260[ 205.798789] ____fput+0xe/0x10[ 205.798792] task_work_run+0x64/0xa0[ 205.798798] exit_to_user_mode_prepare+0x18b/0x190[ 205.798804] syscall_exit_to_user_mode+0x26/0x40[ 205.798808] do_syscall_64+0x69/0x80[ 205.798812] entry_SYSCALL_64_after_hwframe+0x44/0xae[ 205.798827] ------------[ cut here ]------------[ 205.798829] WARNING: CPU: 2 PID: 2605 at lib/ref_tracker.c:136 ref_tracker_free.cold+0x60/0x81[ 205.798837] Modules linked in: rose netrom mkiss ax25 rfcomm cmac algif_hash algif_skcipher af_alg bnep snd_hda_codec_hdmi nls_iso8859_1 i915 rtw88_8821ce rtw88_8821c x86_pkg_temp_thermal rtw88_pci intel_powerclamp rtw88_core snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio coretemp snd_hda_intel kvm_intel snd_intel_dspcfg mac80211 snd_hda_codec kvm i2c_algo_bit drm_buddy drm_dp_helper btusb drm_kms_helper snd_hwdep btrtl snd_hda_core btbcm joydev crct10dif_pclmul btintel crc32_pclmul ghash_clmulni_intel mei_hdcp btmtk intel_rapl_msr aesni_intel bluetooth input_leds snd_pcm crypto_simd syscopyarea processor_thermal_device_pci_legacy sysfillrect cryptd intel_soc_dts_iosf snd_seq sysimgblt ecdh_generic fb_sys_fops rapl libarc4 processor_thermal_device intel_cstate processor_thermal_rfim cec snd_timer ecc snd_seq_device cfg80211 processor_thermal_mbox mei_me processor_thermal_rapl mei rc_core at24 snd intel_pch_thermal intel_rapl_common ttm soundcore int340x_thermal_zone video[ 205.798948] mac_hid acpi_pad sch_fq_codel ipmi_devintf ipmi_msghandler drm msr parport_pc ppdev lp parport ramoops pstore_blk reed_solomon pstore_zone efi_pstore ip_tables x_tables autofs4 hid_generic usbhid hid i2c_i801 i2c_smbus r8169 xhci_pci ahci libahci realtek lpc_ich xhci_pci_renesas [last unloaded: ax25][ 205.798992] CPU: 2 PID: 2605 Comm: ax25ipd Not tainted 5.18.11-F6BVP #3[ 205.798996] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CK3, BIOS 5.011 09/16/2020[ 205.798999] RIP: 0010:ref_tracker_free.cold+0x60/0x81[ 205.799005] Code: e8 d2 01 9b ff 83 7b 18 00 74 14 48 c7 c7 2f d7 ff 98 e8 10 6e fc ff 8b 7b 18 e8 b8 01 9b ff 4c 89 ee 4c 89 e7 e8 5d fd 07 00 <0f> 0b b8 ea ff ff ff e9 30 05 9b ff 41 0f b6 f7 48 c7 c7 a0 fa 4e[ 205.799008] RSP: 0018:ffffaf5281073958 EFLAGS: 00010286[ 205.799011] RAX: 0000000080000000 RBX: ffff9a0bd687ebe0 RCX: 0000000000000000[ 205.799014] RDX: 0000000000000001 RSI: 0000000000000282 RDI: 00000000ffffffff[ 205.799016] RBP: ffffaf5281073a10 R08: 0000000000000003 R09: fffffffffffd5618[ 205.799019] R10: 0000000000ffff10 R11: 000000000000000f R12: ffff9a0bc53384d0[ 205.799022] R13: 0000000000000282 R14: 00000000ae000001 R15: 0000000000000001[ 205.799024] FS: 0000000000000000(0000) GS:ffff9a0d0f300000(0000) knlGS:0000000000000000[ 205.799028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 205.799031] CR2: 00007ff6b8311554 CR3: 000000001ac10004 CR4: 00000000001706e0[ 205.799033] Call Trace:[ 205.799035] [ 205.799038] ? ax25_dev_device_down+0xd9/---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50166 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: When HCI work queue is drained, only queue chained workThe HCI command, event, and data packet processing workqueue is drainedto avoid deadlock in commit76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state").There is another delayed work, which will queue command to this drainedworkqueue. Which results in the following error report:Bluetooth: hci2: command 0x040f tx timeoutWARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140Workqueue: events hci_cmd_timeoutRIP: 0010:__queue_work+0xdad/0x1140RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093RAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08RBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700R10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60R13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800FS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? queue_work_on+0xcb/0x110 ? lockdep_hardirqs_off+0x90/0xd0 queue_work_on+0xee/0x110 process_one_work+0x996/0x1610 ? pwq_dec_nr_in_flight+0x2a0/0x2a0 ? rwlock_bug.part.0+0x90/0x90 ? _raw_spin_lock_irq+0x41/0x50 worker_thread+0x665/0x1080 ? process_one_work+0x1610/0x1610 kthread+0x2e9/0x3a0 ? kthread_complete_and_exit+0x40/0x40 ret_from_fork+0x1f/0x30 To fix this, we can add a new HCI_DRAIN_WQ flag, and don't queue thetimeout workqueue while command workqueue is draining.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50167 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix potential 32-bit overflow when accessing ARRAY map elementIf BPF array map is bigger than 4GB, element pointer calculation canoverflow because both index and elem_size are u32. Fix this everywhereby forcing 64-bit multiplication. Extract this formula into separatesmall helper and use it consistently in various places.Speculative-preventing formula utilizing index_mask trick is left as is,but explicit u64 casts are added in both places.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50174 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hinic: avoid kernel hung in hinic_get_stats64()When using hinic device as a bond slave device, and reading device statsof master bond device, the kernel may hung.The kernel panic calltrace as follows:Kernel panic - not syncing: softlockup: hung tasksCall trace: native_queued_spin_lock_slowpath+0x1ec/0x31c dev_get_stats+0x60/0xcc dev_seq_printf_stats+0x40/0x120 dev_seq_show+0x1c/0x40 seq_read_iter+0x3c8/0x4dc seq_read+0xe0/0x130 proc_reg_read+0xa8/0xe0 vfs_read+0xb0/0x1d4 ksys_read+0x70/0xfc __arm64_sys_read+0x20/0x30 el0_svc_common+0x88/0x234 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180And the calltrace of task that actually caused kernel hungs as follows: __switch_to+124 __schedule+548 schedule+72 schedule_timeout+348 __down_common+188 __down+24 down+104 hinic_get_stats64+44 [hinic] dev_get_stats+92 bond_get_stats+172 [bonding] dev_get_stats+92 dev_seq_printf_stats+60 dev_seq_show+24 seq_read_iter+964 seq_read+220 proc_reg_read+164 vfs_read+172 ksys_read+108 __arm64_sys_read+28 el0_svc_common+132 do_el0_svc+40 el0_svc+24 el0_sync_handler+164 el0_sync+324When getting device stats from bond, kernel will call bond_get_stats().It first holds the spinlock bond->stats_lock, and then callhinic_get_stats64() to collect hinic device's stats.However, hinic_get_stats64() calls `down(&nic_dev->mgmt_lock)` toprotect its critical section, which may schedule current task out.And if system is under high pressure, the task cannot be woken upimmediately, which eventually triggers kernel hung panic.Since previous patch has replaced hinic_dev.tx_stats/rx_stats with localvariable in hinic_get_stats64(), there is nothing need to be protectedby lock, so just removing down()/up() is ok.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50177 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcutorture: Fix ksoftirqd boosting timing and iterationThe RCU priority boosting can fail in two situations:1) If (nr_cpus= > maxcpus=), which means if the total number of CPUsis higher than those brought online at boot, then torture_onoff() maylater bring up CPUs that weren't online on boot. Now since rcutortureinitialization only boosts the ksoftirqds of the CPUs that have beenset online on boot, the CPUs later set online by torture_onoff won'tbenefit from the boost, making RCU priority boosting fail.2) The ksoftirqd kthreads are boosted after the creation ofrcu_torture_boost() kthreads, which opens a window large enough for thesercu_torture_boost() kthreads to wait (despite running at FIFO priority)for ksoftirqds that are still running at SCHED_NORMAL priority.The issues can trigger for example with: ./kvm.sh --configs TREE01 --kconfig "CONFIG_RCU_BOOST=y" [ 34.968561] rcu-torture: !!! [ 34.968627] ------------[ cut here ]------------ [ 35.014054] WARNING: CPU: 4 PID: 114 at kernel/rcu/rcutorture.c:1979 rcu_torture_stats_print+0x5ad/0x610 [ 35.052043] Modules linked in: [ 35.069138] CPU: 4 PID: 114 Comm: rcu_torture_sta Not tainted 5.18.0-rc1 #1 [ 35.096424] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 [ 35.154570] RIP: 0010:rcu_torture_stats_print+0x5ad/0x610 [ 35.198527] Code: 63 1b 02 00 74 02 0f 0b 48 83 3d 35 63 1b 02 00 74 02 0f 0b 48 83 3d 21 63 1b 02 00 74 02 0f 0b 48 83 3d 0d 63 1b 02 00 74 02 <0f> 0b 83 eb 01 0f 8e ba fc ff ff 0f 0b e9 b3 fc ff f82 [ 37.251049] RSP: 0000:ffffa92a0050bdf8 EFLAGS: 00010202 [ 37.277320] rcu: De-offloading 8 [ 37.290367] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001 [ 37.290387] RDX: 0000000000000000 RSI: 00000000ffffbfff RDI: 00000000ffffffff [ 37.290398] RBP: 000000000000007b R08: 0000000000000000 R09: c0000000ffffbfff [ 37.290407] R10: 000000000000002a R11: ffffa92a0050bc18 R12: ffffa92a0050be20 [ 37.290417] R13: ffffa92a0050be78 R14: 0000000000000000 R15: 000000000001bea0 [ 37.290427] FS: 0000000000000000(0000) GS:ffff96045eb00000(0000) knlGS:0000000000000000 [ 37.290448] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.290460] CR2: 0000000000000000 CR3: 000000001dc0c000 CR4: 00000000000006e0 [ 37.290470] Call Trace: [ 37.295049] [ 37.295065] ? preempt_count_add+0x63/0x90 [ 37.295095] ? _raw_spin_lock_irqsave+0x12/0x40 [ 37.295125] ? rcu_torture_stats_print+0x610/0x610 [ 37.295143] rcu_torture_stats+0x29/0x70 [ 37.295160] kthread+0xe3/0x110 [ 37.295176] ? kthread_complete_and_exit+0x20/0x20 [ 37.295193] ret_from_fork+0x22/0x30 [ 37.295218] Fix this with boosting the ksoftirqds kthreads from the boostinghotplug callback itself and before the boosting kthreads are created.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50182 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Align upwards buffer sizeThe hardware can support any image size WxH,with arbitrary W (image width) and H (image height) dimensions.Align upwards buffer size for both encoder and decoder.and leave the picture resolution unchanged.For decoder, the risk of memory out of bounds can be avoided.For both encoder and decoder, the driver will lift the limitation ofresolution alignment.For example, the decoder can support jpeg whose resolution is 227x149the encoder can support nv12 1080P, won't change it to 1920x1072.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50184 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/meson: encoder_hdmi: Fix refcount leak in meson_encoder_hdmi_initof_graph_get_remote_node() returns remote device nodepointer withrefcount incremented, we should use of_node_put() on it when done.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50195 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ARM: dts: qcom: replace gcc PXO with pxo_board fixed clockReplace gcc PXO phandle to pxo_board fixed clock declared in the dts.gcc driver doesn't provide PXO_SRC as it's a fixed-clock. This cause akernel panic if any driver actually try to use it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50214 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:coresight: Clear the connection field properlycoresight devices track their connections (output connections) andhold a reference to the fwnode. When a device goes away, we walk throughthe devices on the coresight bus and make sure that the referencesare dropped. This happens both ways: a) For all output connections from the device, drop the reference to the target device via coresight_release_platform_data()b) Iterate over all the devices on the coresight bus and drop the reference to fwnode if *this* device is the target of the output connection, via coresight_remove_conns()->coresight_remove_match().However, the coresight_remove_match() doesn't clear the fwnode field,after dropping the reference, this causes use-after-free andadditional refcount drops on the fwnode.e.g., if we have two devices, A and B, with a connection, A -> B.If we remove B first, B would clear the reference on B, from Avia coresight_remove_match(). But when A is removed, it still hasa connection with fwnode still pointing to B. Thus it tries to dropsthe reference in coresight_release_platform_data(), raising the bellslike :[ 91.990153] ------------[ cut here ]------------[ 91.990163] refcount_t: addition on 0; use-after-free.[ 91.990212] WARNING: CPU: 0 PID: 461 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144[ 91.990260] Modules linked in: coresight_funnel coresight_replicator coresight_etm4x(-) crct10dif_ce coresight ip_tables x_tables ipv6 [last unloaded: coresight_cpu_debug][ 91.990398] CPU: 0 PID: 461 Comm: rmmod Tainted: G W T 5.19.0-rc2+ #53[ 91.990418] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019[ 91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 91.990454] pc : refcount_warn_saturate+0xa0/0x144[ 91.990476] lr : refcount_warn_saturate+0xa0/0x144[ 91.990496] sp : ffff80000c843640[ 91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27: ffff80000c8439a8[ 91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8[ 91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2[ 91.990659] x20: 0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40[ 91.990708] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80000abf6fa0[ 91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12: 657466612d657375[ 91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9 : ffff8000081aba28[ 91.990854] x8 : 206e6f206e6f6974 x7 : 69646461203a745f x6 : 746e756f63666572[ 91.990903] x5 : ffff00097648ec58 x4 : 0000000000000000 x3 : 0000000000000027[ 91.990952] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080260ba00[ 91.991000] Call trace:[ 91.991012] refcount_warn_saturate+0xa0/0x144[ 91.991034] kobject_get+0xac/0xb0[ 91.991055] of_node_get+0x2c/0x40[ 91.991076] of_fwnode_get+0x40/0x60[ 91.991094] fwnode_handle_get+0x3c/0x60[ 91.991116] fwnode_get_nth_parent+0xf4/0x110[ 91.991137] fwnode_full_name_string+0x48/0xc0[ 91.991158] device_node_string+0x41c/0x530[ 91.991178] pointer+0x320/0x3ec[ 91.991198] vsnprintf+0x23c/0x750[ 91.991217] vprintk_store+0x104/0x4b0[ 91.991238] vprintk_emit+0x8c/0x360[ 91.991257] vprintk_default+0x44/0x50[ 91.991276] vprintk+0xcc/0xf0[ 91.991295] _printk+0x68/0x90[ 91.991315] of_node_release+0x13c/0x14c[ 91.991334] kobject_put+0x98/0x114[ 91.991354] of_node_put+0x24/0x34[ 91.991372] of_fwnode_put+0x40/0x5c[ 91.991390] fwnode_handle_put+0x38/0x50[ 91.991411] coresight_release_platform_data+0x74/0xb0 [coresight][ 91.991472] coresight_unregister+0x64/0xcc [coresight][ 91.991525] etm4_remove_dev+0x64/0x78 [coresight_etm4x][ 91.991563] etm4_remove_amba+0x1c/0x2c [coresight_etm4x][ 91.991598] amba_remove+0x3c/0x19c---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50219 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix KASAN use-after-free Read in compute_effective_progsSyzbot found a Use After Free bug in compute_effective_progs().The reproducer creates a number of BPF links, and causes a faultinjected alloc to fail, while calling bpf_link_detach on them.Link detach triggers the link to be freed by bpf_link_free(),which calls __cgroup_bpf_detach() and update_effective_progs().If the memory allocation in this function fails, the function restoresthe pointer to the bpf_cgroup_link on the cgroup list, but the memorygets freed just after it returns. After this, every subsequent call toupdate_effective_progs() causes this already deallocated pointer to bedereferenced in prog_list_length(), and triggers KASAN UAF error.To fix this issue don't preserve the pointer to the prog or link in thelist, but remove it and replace it with a dummy prog without shrinkingthe table. The subsequent call to __cgroup_bpf_detach() or__cgroup_bpf_detach() will correct it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50224 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86/mmu: Treat NX as a valid SPTE bit for NPTTreat the NX bit as valid when using NPT, as KVM will set the NX bit whenthe NX huge page mitigation is enabled (mindblowing) and trigger the WARNthat fires on reserved SPTE bits being set.KVM has required NX support for SVM since commit b26a71a1a5b9 ("KVM: SVM:Refuse to load kvm_amd if NX support is not available") for exactly thisreason, but apparently it never occurred to anyone to actually test NPTwith the mitigation enabled. ------------[ cut here ]------------ spte = 0x800000018a600ee7, level = 2, rsvd bits = 0x800f0000001fe000 WARNING: CPU: 152 PID: 15966 at arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm] Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/27/2022 RIP: 0010:make_spte+0x327/0x340 [kvm] Call Trace: tdp_mmu_map_handle_target_level+0xc3/0x230 [kvm] kvm_tdp_mmu_map+0x343/0x3b0 [kvm] direct_page_fault+0x1ae/0x2a0 [kvm] kvm_tdp_page_fault+0x7d/0x90 [kvm] kvm_mmu_page_fault+0xfb/0x2e0 [kvm] npf_interception+0x55/0x90 [kvm_amd] svm_invoke_exit_handler+0x31/0xf0 [kvm_amd] svm_handle_exit+0xf6/0x1d0 [kvm_amd] vcpu_enter_guest+0xb6d/0xee0 [kvm] ? kvm_pmu_trigger_event+0x6d/0x230 [kvm] vcpu_run+0x65/0x2c0 [kvm] kvm_arch_vcpu_ioctl_run+0x355/0x610 [kvm] kvm_vcpu_ioctl+0x551/0x610 [kvm] __se_sys_ioctl+0x77/0xc0 __x64_sys_ioctl+0x1d/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50225 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:riscv:uprobe fix SR_SPIE set/clear handlingIn riscv the process of uprobe going to clear spie before execthe origin insn,and set spie after that.But When access the pagewhich origin insn has been placed a page fault may happen andirq was disabled in arch_uprobe_pre_xol function,It cause a WARNas follows.There is no need to clear/set spie in arch_uprobe_pre/post/abort_xol.We can just remove it.[ 31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488[ 31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work[ 31.684929] preempt_count: 0, expected: 0[ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G[ 31.686542] Hardware name: riscv-virtio,qemu (DT)[ 31.686797] Call Trace:[ 31.687053] [] dump_backtrace+0x30/0x38[ 31.687699] [] show_stack+0x40/0x4c[ 31.688141] [] dump_stack_lvl+0x44/0x5c[ 31.688396] [] dump_stack+0x18/0x20[ 31.688653] [] __might_resched+0x114/0x122[ 31.688948] [] __might_sleep+0x50/0x7a[ 31.689435] [] down_read+0x30/0x130[ 31.689728] [] do_page_fault+0x166/x446[ 31.689997] [] ret_from_exception+0x0/0xc

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50236 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: Fix crash on isr after kexec()If the system is rebooted via isr(), the IRQ handler mightbe triggered before the domain is initialized. Resulting onan invalid memory access error.Fix:[ 0.500930] Unable to handle kernel read from unreadable memory at virtual address 0000000000000070[ 0.501166] Call trace:[ 0.501174] report_iommu_fault+0x28/0xfc[ 0.501180] mtk_iommu_isr+0x10c/0x1c0[ joro: Fixed spelling in commit message ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50242 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init()If vp alloc failed in qlcnic_sriov_init(), all previously allocated vpneeds to be freed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50243 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: handle the error returned from sctp_auth_asoc_init_active_keyWhen it returns an error from sctp_auth_asoc_init_active_key(), theactive_key is actually not updated. The old sh_key will be freeedwhile it's still used as active key in asoc. Then an use-after-freewill be triggered when sending patckets, as found by syzbot: sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:132 [inline] sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863 sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734This patch is to fix it by not replacing the sh_key when it returnserrors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key().For sctp_auth_set_active_key(), old active_key_id will be set backto asoc->active_key_id when the same thing happens.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50244 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter()If device_register() fails in cxl_pci_afu|adapter(), the deviceis not added, device_unregister() can not be called in the errorpath, otherwise it will cause a null-ptr-deref because of removingnot added device.As comment of device_register() says, it should use put_device() to giveup the reference in the error path. So split device_unregister() intodevice_del() and put_device(), then goes to put dev when register fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50259 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: fix race in sock_map_free()sock_map_free() calls release_sock(sk) without owning a referenceon the socket. This can cause use-after-free as syzbot found [1]Jakub Sitnicki already took care of a similar issuein sock_hash_free() in commit 75e68e5bf2c7 ("bpf, sockhash:Synchronize delete from bucket list on map free")[1]refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31Modules linked in:CPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Workqueue: events_unbound bpf_map_free_deferredRIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ffRSP: 0018:ffffc9000456fb60 EFLAGS: 00010246RAX: eae59bab72dcd700 RBX: 0000000000000004 RCX: ffff8880207057c0RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000RBP: 0000000000000004 R08: ffffffff816fdabd R09: fffff520008adee5R10: fffff520008adee5 R11: 1ffff920008adee4 R12: 0000000000000004R13: dffffc0000000000 R14: ffff88807b1c6c00 R15: 1ffff1100f638dcfFS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30c30000 CR3: 000000000d08e000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:__refcount_dec include/linux/refcount.h:344 [inline]refcount_dec include/linux/refcount.h:359 [inline]__sock_put include/net/sock.h:779 [inline]tcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092release_sock+0xaf/0x1c0 net/core/sock.c:3468sock_map_free+0x219/0x2c0 net/core/sock_map.c:356process_one_work+0x81c/0xd10 kernel/workqueue.c:2289worker_thread+0xb14/0x1330 kernel/workqueue.c:2436kthread+0x266/0x300 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50265 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kcm: annotate data-races around kcm->rx_waitkcm->rx_psock can be read locklessly in kcm_rfree().Annotate the read and writes accordingly.syzbot reported:BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfreewrite to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1:reserve_rx_kcm net/kcm/kcmsock.c:283 [inline]kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301strp_recv+0x6d/0x80 net/strparser/strparser.c:335tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703strp_read_sock net/strparser/strparser.c:358 [inline]do_strp_work net/strparser/strparser.c:406 [inline]strp_work+0xe8/0x180 net/strparser/strparser.c:415process_one_work+0x3d3/0x720 kernel/workqueue.c:2289worker_thread+0x618/0xa70 kernel/workqueue.c:2436kthread+0x1a9/0x1e0 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0:kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841skb_release_all net/core/skbuff.c:852 [inline]__kfree_skb net/core/skbuff.c:868 [inline]kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891kfree_skb include/linux/skbuff.h:1216 [inline]kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161____sys_recvmsg+0x16c/0x2e0___sys_recvmsg net/socket.c:2743 [inline]do_recvmmsg+0x2f1/0x710 net/socket.c:2837__sys_recvmmsg net/socket.c:2916 [inline]__do_sys_recvmmsg net/socket.c:2939 [inline]__se_sys_recvmmsg net/socket.c:2932 [inline]__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x01 -> 0x00Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50273 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on destination blkaddr during recoveryAs Wenqing Liu reported in bugzilla:https://bugzilla.kernel.org/show_bug.cgi?id=216456loop5: detected capacity change from 0 to 131072F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0F2FS-fs (loop5): Bitmap was wrongly set, blk:5634------------[ cut here ]------------WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs]Call Trace: f2fs_do_replace_block+0xa98/0x1890 [f2fs] f2fs_replace_block+0xeb/0x180 [f2fs] recover_data+0x1a69/0x6ae0 [f2fs] f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs] f2fs_fill_super+0x4665/0x61e0 [f2fs] mount_bdev+0x2cf/0x3b0 legacy_get_tree+0xed/0x1d0 vfs_get_tree+0x81/0x2b0 path_mount+0x47e/0x19d0 do_mount+0xce/0xf0 __x64_sys_mount+0x12c/0x1a0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdIf we enable CONFIG_F2FS_CHECK_FS config, it will trigger a kernel panicinstead of warning.The root cause is: in fuzzed image, SIT table is inconsistent with inodemapping table, result in triggering such warning during SIT table update.This patch introduces a new flag DATA_GENERIC_ENHANCE_UPDATE, w/ thisflag, data block recovery flow can check destination blkaddr's validationin SIT table, and skip f2fs_replace_block() to avoid inconsistent status.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50281 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:MIPS: SGI-IP27: Fix platform-device leak in bridge_platform_create()In error case in bridge_platform_create after callingplatform_device_add()/platform_device_add_data()/platform_device_add_resources(), release the failed'pdev' or it will be leak, call platform_device_put()to fix this problem.Besides, 'pdev' is divided into 'pdev_wd' and 'pdev_bd',use platform_device_unregister() to release sgi_w1resources when xtalk-bridge registration fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50285 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pagesThe h->*_huge_pages counters are protected by the hugetlb_lock, butalloc_huge_page has a corner case where it can decrement the counteroutside of the lock.This could lead to a corrupted value of h->resv_huge_pages, which we haveobserved on our systems.Take the hugetlb_lock before decrementing h->resv_huge_pages to avoid apotential race.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50291 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kcm: annotate data-races around kcm->rx_psockkcm->rx_psock can be read locklessly in kcm_rfree().Annotate the read and writes accordingly.We do the same for kcm->rx_wait in the following patch.syzbot reported:BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcmwrite to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1:unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301strp_recv+0x6d/0x80 net/strparser/strparser.c:335tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703strp_read_sock net/strparser/strparser.c:358 [inline]do_strp_work net/strparser/strparser.c:406 [inline]strp_work+0xe8/0x180 net/strparser/strparser.c:415process_one_work+0x3d3/0x720 kernel/workqueue.c:2289worker_thread+0x618/0xa70 kernel/workqueue.c:2436kthread+0x1a9/0x1e0 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0:kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841skb_release_all net/core/skbuff.c:852 [inline]__kfree_skb net/core/skbuff.c:868 [inline]kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891kfree_skb include/linux/skbuff.h:1216 [inline]kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161____sys_recvmsg+0x16c/0x2e0___sys_recvmsg net/socket.c:2743 [inline]do_recvmmsg+0x2f1/0x710 net/socket.c:2837__sys_recvmmsg net/socket.c:2916 [inline]__do_sys_recvmmsg net/socket.c:2939 [inline]__se_sys_recvmmsg net/socket.c:2932 [inline]__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0xffff88812971ce00 -> 0x0000000000000000Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50293 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a rangeIf we get -ENOMEM while dropping file extent items in a given range, atbtrfs_drop_extents(), due to failure to allocate memory when attempting toincrement the reference count for an extent or drop the reference count,we handle it with a BUG_ON(). This is excessive, instead we can simplyabort the transaction and return the error to the caller. In fact mostcallers of btrfs_drop_extents(), directly or indirectly, already abortthe transaction if btrfs_drop_extents() returns any error.Also, we already have error paths at btrfs_drop_extents() that may return-ENOMEM and in those cases we abort the transaction, like for exampleanything that changes the b+tree may return -ENOMEM due to a failure toallocate a new extent buffer when COWing an existing extent buffer, suchas a call to btrfs_duplicate_item() for example.So replace the BUG_ON() calls with proper logic to abort the transactionand return the error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50300 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix extent map use-after-free when handling missing device in read_one_chunkStore the error code before freeing the extent_map. Though it'sreference counted structure, in that function it's the first and lastallocation so this would lead to a potential use-after-free.The error can happen eg. when chunk is stored on a missing device andthe degraded mount option is missing.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216721

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50303 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix double release compute pasidIf kfd_process_device_init_vm returns failure after vm is converted tocompute vm and vm->pasid set to compute pasid, KFD will not takepdd->drm_file reference. As a result, drm close file handler maybecalled to release the compute pasid before KFD process destroy worker torelease the same pasid and set vm->pasid to zero, this generates belowWARNING backtrace and NULL pointer access.Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last stepof kfd_process_device_init_vm, to ensure vm pasid is the original pasidif acquiring vm failed or is the compute pasid with pdd->drm_filereference taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50304 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: core: fix possible resource leak in init_mtd()I got the error report while inject fault in init_mtd():sysfs: cannot create duplicate filename '/devices/virtual/bdi/mtd-0'Call Trace: dump_stack_lvl+0x67/0x83 sysfs_warn_dup+0x60/0x70 sysfs_create_dir_ns+0x109/0x120 kobject_add_internal+0xce/0x2f0 kobject_add+0x98/0x110 device_add+0x179/0xc00 device_create_groups_vargs+0xf4/0x100 device_create+0x7b/0xb0 bdi_register_va.part.13+0x58/0x2d0 bdi_register+0x9b/0xb0 init_mtd+0x62/0x171 [mtd] do_one_initcall+0x6c/0x3c0 do_init_module+0x58/0x222 load_module+0x268e/0x27d0 __do_sys_finit_module+0xd5/0x140 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd kobject_add_internal failed for mtd-0 with -EEXIST, don't try to register things with the same name in the same directory.Error registering mtd class or bdi: -17If init_mtdchar() fails in init_mtd(), mtd_bdi will not be unregistered,as a result, we can't load the mtd module again, to fix this by callingbdi_unregister(mtd_bdi) after out_procfs label.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50311 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cxl: Fix refcount leak in cxl_calc_capp_routingof_get_next_parent() returns a node pointer with refcount incremented,we should use of_node_put() on it when not need anymore.This function only calls of_node_put() in normal path,missing it in the error path.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50313 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: fix order >= MAX_ORDER warning due to crafted negative i_sizeAs syzbot reported [1], the root cause is that i_size field is asigned type, and negative i_size is also less than EROFS_BLKSIZ.As a consequence, it's handled as fast symlink unexpectedly.Let's fall back to the generic path to deal with such unusual i_size.[1] https://lore.kernel.org/r/000000000000ac8efa05e7feaa1f@google.com

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50316 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: Fix kmemleak in orangefs_sysfs_init()When insert and remove the orangefs module, there are kobjects memoryleaked as below:unreferenced object 0xffff88810f95af00 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): a0 83 af 01 81 88 ff ff 08 af 95 0f 81 88 ff ff ................ 08 af 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005a6e4dfe>] orangefs_sysfs_init+0x42/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ae80 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): c8 90 0f 02 81 88 ff ff 88 ae 95 0f 81 88 ff ff ................ 88 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000001a4841fa>] orangefs_sysfs_init+0xc7/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ae00 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 60 87 a1 00 81 88 ff ff 08 ae 95 0f 81 88 ff ff `............... 08 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005915e797>] orangefs_sysfs_init+0x12b/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ad80 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 78 90 0f 02 81 88 ff ff 88 ad 95 0f 81 88 ff ff x............... 88 ad 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000007a14eb35>] orangefs_sysfs_init+0x1ac/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ac00 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.531s) hex dump (first 32 bytes): e0 ff 67 02 81 88 ff ff 08 ac 95 0f 81 88 ff ff ..g............. 08 ac 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000001f38adcb>] orangefs_sysfs_init+0x291/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50319 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:coresight: trbe: remove cpuhp instance node before remove cpuhp statecpuhp_state_add_instance() and cpuhp_state_remove_instance() shouldbe used in pairs. Or there will lead to the warn oncpuhp_remove_multi_state() since the cpuhp_step list is not empty.The following is the error log with 'rmmod coresight-trbe':Error: Removing state 215 which has instances left.Call trace: __cpuhp_remove_state_cpuslocked+0x144/0x160 __cpuhp_remove_state+0xac/0x100 arm_trbe_device_remove+0x2c/0x60 [coresight_trbe] platform_remove+0x34/0x70 device_remove+0x54/0x90 device_release_driver_internal+0x1e4/0x250 driver_detach+0x5c/0xb0 bus_remove_driver+0x64/0xc0 driver_unregister+0x3c/0x70 platform_driver_unregister+0x20/0x30 arm_trbe_exit+0x1c/0x658 [coresight_trbe] __arm64_sys_delete_module+0x1ac/0x24c invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x58/0x1a0 do_el0_svc+0x38/0xd0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0x1ac/0x1b0 el0t_64_sync+0x19c/0x1a0 ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50335 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:9p: set req refcount to zero to avoid uninitialized usageWhen a new request is allocated, the refcount will be zero if it isreused, but if the request is newly allocated from slab, it is not fullyinitialized before being added to idr.If the p9_read_work got a response before the refcount initiated. It willuse a uninitialized req, which will result in a bad request data struct.Here is the logs from syzbot.Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x000x00 0x00 . . . . . . . . ] (in kfence-#110): p9_fcall_fini net/9p/client.c:248 [inline] p9_req_put net/9p/client.c:396 [inline] p9_req_put+0x208/0x250 net/9p/client.c:390 p9_client_walk+0x247/0x540 net/9p/client.c:1165 clone_fid fs/9p/fid.h:21 [inline] v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118 v9fs_xattr_set fs/9p/xattr.c:100 [inline] v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159 __vfs_setxattr+0x119/0x180 fs/xattr.c:182 __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277 vfs_setxattr+0x143/0x340 fs/xattr.c:309 setxattr+0x146/0x160 fs/xattr.c:617 path_setxattr+0x197/0x1c0 fs/xattr.c:636 __do_sys_setxattr fs/xattr.c:652 [inline] __se_sys_setxattr fs/xattr.c:648 [inline] __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82Below is a similar scenario, the scenario in the syzbot log looks morecomplicated than this one, but this patch can fix it. T21124 p9_read_work======================== second trans =================================p9_client_walk p9_client_rpc p9_client_prepare_req p9_tag_alloc req = kmem_cache_alloc(p9_req_cache, GFP_NOFS); tag = idr_alloc << preempted >> req->tc.tag = tag; /* req->[refcount/tag] == uninitialized */ m->rreq = p9_tag_lookup(m->client, m->rc.tag); /* increments uninitalized refcount */ refcount_set(&req->refcount, 2); /* cb drops one ref */ p9_client_cb(req) /* reader thread drops its ref: request is incorrectly freed */ p9_req_put(req) /* use after free and ref underflow */ p9_req_put(req)To fix it, we can initialize the refcount to zero before add to idr.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50337 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocxl: fix pci device refcount leak when calling get_function_0()get_function_0() calls pci_get_domain_bus_and_slot(), as commentsays, it returns a pci device with refcount increment, so afterusing it, pci_dev_put() needs be called.Get the device reference when get_function_0() is not called, sopci_dev_put() can be called in the error path and callersunconditionally. And add comment above get_dvsec_vendor0() to tellcallers to call pci_dev_put().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50338 Severity: Moderate CVSS3 score: 5.5

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

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50352 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns: fix possible memory leak in hnae_ae_register()Inject fault while probing module, if device_register() fails,but the refcount of kobject is not decreased to 0, the nameallocated in dev_set_name() is leaked. Fix this by callingput_device(), so that name can be freed in callback functionkobject_cleanup().unreferenced object 0xffff00c01aba2100 (size 128): comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s) hex dump (first 32 bytes): 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0 [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0 [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390 [<000000006c0ffb13>] kvasprintf+0x8c/0x118 [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8 [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0 [<000000000b87affc>] dev_set_name+0x7c/0xa0 [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae] [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf] [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50354 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix kfd_process_device_init_vm error handlingShould only destroy the ib_mem and let process cleanup worker to freethe outstanding BOs. Reset the pointer in pdd->qpd structure, to avoidNULL pointer access in process destroy worker. BUG: kernel NULL pointer dereference, address: 0000000000000010 Call Trace: amdgpu_amdkfd_gpuvm_unmap_gtt_bo_from_kernel+0x46/0xb0 [amdgpu] kfd_process_device_destroy_cwsr_dgpu+0x40/0x70 [amdgpu] kfd_process_destroy_pdds+0x71/0x190 [amdgpu] kfd_process_wq_release+0x2a2/0x3b0 [amdgpu] process_one_work+0x2a1/0x600 worker_thread+0x39/0x3d0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50356 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: sfb: fix null pointer access issue when sfb_init() failsWhen the default qdisc is sfb, if the qdisc of dev_queue fails to beinited during mqprio_init(), sfb_reset() is invoked to clear resources.In this case, the q->qdisc is NULL, and it will cause gpf issue.The process is as follows:qdisc_create_dflt() sfb_init() tcf_block_get() --->failed, q->qdisc is NULL ... qdisc_put() ... sfb_reset() qdisc_reset(q->qdisc) --->q->qdisc is NULL ops = qdisc->opsThe following is the Call Trace information:general protection fault, probably for non-canonical address0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]RIP: 0010:qdisc_reset+0x2b/0x6f0Call Trace:sfb_reset+0x37/0xd0qdisc_reset+0xed/0x6f0qdisc_destroy+0x82/0x4c0qdisc_put+0x9e/0xb0qdisc_create_dflt+0x2c3/0x4a0mqprio_init+0xa71/0x1760qdisc_create+0x3eb/0x1000tc_modify_qdisc+0x408/0x1720rtnetlink_rcv_msg+0x38e/0xac0netlink_rcv_skb+0x12d/0x3a0netlink_unicast+0x4a2/0x740netlink_sendmsg+0x826/0xcc0sock_sendmsg+0xc5/0x100____sys_sendmsg+0x583/0x690___sys_sendmsg+0xe8/0x160__sys_sendmsg+0xbf/0x160do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0RIP: 0033:0x7f2164122d04

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50357 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: core: fix some leaks in probeThe dwc3_get_properties() function calls: dwc->usb_psy = power_supply_get_by_name(usb_psy_name);so there is some additional clean up required on these error paths.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50365 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:skbuff: Account for tail adjustment during pull operationsExtending the tail can have some unexpected side effects if a program usesa helper like BPF_FUNC_skb_pull_data to read partial content beyond thehead skb headlen when all the skbs in the gso frag_list are linear with nohead_frag - kernel BUG at net/core/skbuff.c:4219! pc : skb_segment+0xcf4/0xd2c lr : skb_segment+0x63c/0xd2c Call trace: skb_segment+0xcf4/0xd2c __udp_gso_segment+0xa4/0x544 udp4_ufo_fragment+0x184/0x1c0 inet_gso_segment+0x16c/0x3a4 skb_mac_gso_segment+0xd4/0x1b0 __skb_gso_segment+0xcc/0x12c udp_rcv_segment+0x54/0x16c udp_queue_rcv_skb+0x78/0x144 udp_unicast_rcv_skb+0x8c/0xa4 __udp4_lib_rcv+0x490/0x68c udp_rcv+0x20/0x30 ip_protocol_deliver_rcu+0x1b0/0x33c ip_local_deliver+0xd8/0x1f0 ip_rcv+0x98/0x1a4 deliver_ptype_list_skb+0x98/0x1ec __netif_receive_skb_core+0x978/0xc60Fix this by marking these skbs as GSO_DODGY so segmentation can handlethe tail updates accordingly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50382 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:padata: Always leave BHs disabled when running ->parallel()A deadlock can happen when an overloaded system runs ->parallel() in thecontext of the current task: padata_do_parallel ->parallel() pcrypt_aead_enc/dec padata_do_serial spin_lock(&reorder->lock) // BHs still enabled ... __do_softirq ... padata_do_serial spin_lock(&reorder->lock)It's a bug for BHs to be on in _do_serial as Steffen points out, soensure they're off in the "current task" case like they are inpadata_parallel_worker to avoid this situation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50384 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:staging: vme_user: Fix possible UAF in tsi148_dma_list_addSmatch report warning as follows:drivers/staging/vme_user/vme_tsi148.c:1757 tsi148_dma_list_add() warn: '&entry->list' not removed from listIn tsi148_dma_list_add(), the error path "goto err_dma" will notremove entry->list from list->entries, but entry will be freed,then list traversal may cause UAF.Fix by removeing it from list->entries before free().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50387 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hinic: fix the issue of CMDQ memory leaksWhen hinic_set_cmdq_depth() fails in hinic_init_cmdqs(), the cmdq memory isnot released correctly. Fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50390 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATEDShifting signed 32-bit value by 31 bits is undefined, so changingsignificant bit to unsigned. The UBSAN warning calltrace like below:UBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26left shift of 1 by 31 places cannot be represented in type 'int'Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c ttm_bo_move_memcpy+0x3b4/0x460 [ttm] bo_driver_move+0x32/0x40 [drm_vram_helper] ttm_bo_handle_move_mem+0x118/0x200 [ttm] ttm_bo_validate+0xfa/0x220 [ttm] drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper] drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper] drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper] drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper] drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper] drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper] drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper] drm_atomic_commit+0x9c/0x160 [drm] drm_client_modeset_commit_atomic+0x33a/0x380 [drm] drm_client_modeset_commit_locked+0x77/0x220 [drm] drm_client_modeset_commit+0x31/0x60 [drm] __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper] drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper] fbcon_init+0x316/0x790 visual_init+0x113/0x1d0 do_bind_con_driver+0x2a3/0x5c0 do_take_over_console+0xa9/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50396 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: fix memory leak in tcindex_set_parmsSyzkaller reports a memory leak as follows:====================================BUG: memory leakunreferenced object 0xffff88810c287f00 (size 256): comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s) 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 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [] kmalloc include/linux/slab.h:576 [inline] [] kmalloc_array include/linux/slab.h:627 [inline] [] kcalloc include/linux/slab.h:659 [inline] [] tcf_exts_init include/net/pkt_cls.h:250 [inline] [] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342 [] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553 [] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147 [] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082 [] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540 [] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] [] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [] sock_sendmsg_nosec net/socket.c:714 [inline] [] sock_sendmsg+0x56/0x80 net/socket.c:734 [] ____sys_sendmsg+0x178/0x410 net/socket.c:2482 [] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [] __sys_sendmmsg+0x105/0x330 net/socket.c:2622 [] __do_sys_sendmmsg net/socket.c:2651 [inline] [] __se_sys_sendmmsg net/socket.c:2648 [inline] [] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd====================================Kernel uses tcindex_change() to change an existingfilter properties.Yet the problem is that, during the process of changing,if `old_r` is retrieved from `p->perfect`, thenkernel uses tcindex_alloc_perfect_hash() to newlyallocate filter results, uses tcindex_filter_result_init()to clear the old filter result, without destroyingits tcf_exts structure, which triggers the above memory leak.To be more specific, there are only two source for the `old_r`,according to the tcindex_lookup(). `old_r` is retrieved from`p->perfect`, or `old_r` is retrieved from `p->h`. * If `old_r` is retrieved from `p->perfect`, kernel usestcindex_alloc_perfect_hash() to newly allocate thefilter results. Then `r` is assigned with `cp->perfect + handle`,which is newly allocated. So condition `old_r && old_r != r` istrue in this situation, and kernel uses tcindex_filter_result_init()to clear the old filter result, without destroyingits tcf_exts structure * If `old_r` is retrieved from `p->h`, then `p->perfect` is NULLaccording to the tcindex_lookup(). Considering that `cp->h`is directly copied from `p->h` and `p->perfect` is NULL,`r` is assigned with `tcindex_lookup(cp, handle)`, whose valueshould be the same as `old_r`, so condition `old_r && old_r != r`is false in this situation, kernel ignores usingtcindex_filter_result_init() to clear the old filter result.So only when `old_r` is retrieved from `p->perfect` does kernel usetcindex_filter_result_init() to clear the old filter result, whichtriggers the above memory leak.Considering that there already exists a tc_filter_wq workqueueto destroy the old tcindex_d---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50406 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iomap: iomap: fix memory corruption when recording errors during writebackEvery now and then I see this crash on arm64:Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8Buffer I/O error on dev dm-0, logical block 8733687, async page readMem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation faultData abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000[00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000Internal error: Oops: 96000006 [#1] PREEMPT SMPBuffer I/O error on dev dm-0, logical block 8733688, async page readDumping ftrace buffer:Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty)XFS (dm-0): log I/O error -5Modules linked in: dm_thin_pool dm_persistent_dataXFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296). dm_bio_prisonXFS (dm-0): Please unmount the filesystem and rectify the problem(s)XFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0 dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECTpotentially unexpected fatal signal 6. nf_reject_ipv6potentially unexpected fatal signal 6. ipt_REJECT nf_reject_ipv4CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tablesHardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) ip_tablespc : 000003fd6d7df200 x_tableslr : 000003fd6d7df1ec overlay nfsv4CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021Workqueue: writeback wb_workfnsp : 000003ffd9522fd0 (flush-253:0)pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--)pc : errseq_set+0x1c/0x100x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000x23: 00000000ffffffff x22: 0000000000000005lr : __filemap_set_wb_err+0x24/0xe0 x21: 0000000000000006sp : fffffe000f80f760x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8Call trace: errseq_set+0x1c/0x100 __filemap_set_wb_err+0x24/0xe0 iomap_do_writepage+0x5e4/0xd5c write_cache_pages+0x208/0x674 iomap_writepages+0x34/0x60 xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b]x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffeex5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000CPU: ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50412 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm: bridge: adv7511: unregister cec i2c device after cec adaptercec_unregister_adapter() assumes that the underlying adapter ops arecallable. For example, if the CEC adapter currently has a valid physicaladdress, then the unregistration procedure will invalidate the physicaladdress by setting it to f.f.f.f. Whence the following kernel oopsobserved after removing the adv7511 module: Unable to handle kernel execution of user memory at virtual address 0000000000000000 Internal error: Oops: 86000004 [#1] PREEMPT_RT SMP Call trace: 0x0 adv7511_cec_adap_log_addr+0x1ac/0x1c8 [adv7511] cec_adap_unconfigure+0x44/0x90 [cec] __cec_s_phys_addr.part.0+0x68/0x230 [cec] __cec_s_phys_addr+0x40/0x50 [cec] cec_unregister_adapter+0xb4/0x118 [cec] adv7511_remove+0x60/0x90 [adv7511] i2c_device_remove+0x34/0xe0 device_release_driver_internal+0x114/0x1f0 driver_detach+0x54/0xe0 bus_remove_driver+0x60/0xd8 driver_unregister+0x34/0x60 i2c_del_driver+0x2c/0x68 adv7511_exit+0x1c/0x67c [adv7511] __arm64_sys_delete_module+0x154/0x288 invoke_syscall+0x48/0x100 el0_svc_common.constprop.0+0x48/0xe8 do_el0_svc+0x28/0x88 el0_svc+0x1c/0x50 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x15c/0x160 Code: bad PC value ---[ end trace 0000000000000000 ]---Protect against this scenario by unregistering i2c_cec afterunregistering the CEC adapter. Duly disable the CEC clock afterwardstoo.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50416 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/wpcm450: Fix memory leak in wpcm450_aic_of_init()If of_iomap() failed, 'aic' should be freed before return. Otherwisethere is a memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50418 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: mhi: fix potential memory leak in ath11k_mhi_register()mhi_alloc_controller() allocates a memory space for mhi_ctrl. When getssome error, mhi_ctrl should be freed with mhi_free_controller(). Butwhen ath11k_mhi_read_addr_from_dt() fails, the function returns withoutcalling mhi_free_controller(), which will lead to a memory leak.We can fix it by calling mhi_free_controller() whenath11k_mhi_read_addr_from_dt() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50438 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hinic: fix memory leak when reading function tableWhen the input parameter idx meets the expected case option inhinic_dbg_get_func_table(), read_data is not released. Fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50452 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: cake: fix null pointer access issue when cake_init() failsWhen the default qdisc is cake, if the qdisc of dev_queue fails to beinited during mqprio_init(), cake_reset() is invoked to clearresources. In this case, the tins is NULL, and it will cause gpf issue.The process is as follows:qdisc_create_dflt() cake_init() q->tins = kvcalloc(...) --->failed, q->tins is NULL ... qdisc_put() ... cake_reset() ... cake_dequeue_one() b = &q->tins[...] --->q->tins is NULLThe following is the Call Trace information:general protection fault, probably for non-canonical address0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]RIP: 0010:cake_dequeue_one+0xc9/0x3c0Call Trace:cake_reset+0xb1/0x140qdisc_reset+0xed/0x6f0qdisc_destroy+0x82/0x4c0qdisc_put+0x9e/0xb0qdisc_create_dflt+0x2c3/0x4a0mqprio_init+0xa71/0x1760qdisc_create+0x3eb/0x1000tc_modify_qdisc+0x408/0x1720rtnetlink_rcv_msg+0x38e/0xac0netlink_rcv_skb+0x12d/0x3a0netlink_unicast+0x4a2/0x740netlink_sendmsg+0x826/0xcc0sock_sendmsg+0xc5/0x100____sys_sendmsg+0x583/0x690___sys_sendmsg+0xe8/0x160__sys_sendmsg+0xbf/0x160do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0RIP: 0033:0x7f89e5122d04

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50461 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: ti: am65-cpsw: Fix PM runtime leakage in am65_cpsw_nuss_ndo_slave_open()Ensure pm_runtime_put() is issued in error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50464 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7915: Fix PCI device refcount leak in mt7915_pci_init_hif2()As comment of pci_get_device() says, it returns a pci_device with itsrefcount increased. We need to call pci_dev_put() to decrease therefcount. Save the return value of pci_get_device() and callpci_dev_put() to decrease the refcount.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50473 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: Init completion before kobject_init_and_add()In cpufreq_policy_alloc(), it will call uninitialed completion incpufreq_sysfs_release() when kobject_init_and_add() fails. Andthat will cause a crash such as the following page fault in complete:BUG: unable to handle page fault for address: fffffffffffffff8[..]RIP: 0010:complete+0x98/0x1f0[..]Call Trace: kobject_put+0x1be/0x4c0 cpufreq_online.cold+0xee/0x1fd cpufreq_add_dev+0x183/0x1e0 subsys_interface_register+0x3f5/0x4e0 cpufreq_register_driver+0x3b7/0x670 acpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq] do_one_initcall+0x13d/0x780 do_init_module+0x1c3/0x630 load_module+0x6e67/0x73b0 __do_sys_finit_module+0x181/0x240 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50481 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter()If device_register() fails in cxl_register_afu|adapter(), the deviceis not added, device_unregister() can not be called in the error path,otherwise it will cause a null-ptr-deref because of removing not addeddevice.As comment of device_register() says, it should use put_device() to giveup the reference in the error path. So split device_unregister() intodevice_del() and put_device(), then goes to put dev when register fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50500 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: fix memory leak in nsim_drv_probe() when nsim_dev_resources_register() failedIf some items in nsim_dev_resources_register() fail, memory leak willoccur. The following is the memory leak information.unreferenced object 0xffff888074c02600 (size 128): comm "echo", pid 8159, jiffies 4294945184 (age 493.530s) hex dump (first 32 bytes): 40 47 ea 89 ff ff ff ff 01 00 00 00 00 00 00 00 @G.............. ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace: [<0000000011a31c98>] kmalloc_trace+0x22/0x60 [<0000000027384c69>] devl_resource_register+0x144/0x4e0 [<00000000a16db248>] nsim_drv_probe+0x37a/0x1260 [<000000007d1f448c>] really_probe+0x20b/0xb10 [<00000000c416848a>] __driver_probe_device+0x1b3/0x4a0 [<00000000077e0351>] driver_probe_device+0x49/0x140 [<0000000054f2465a>] __device_attach_driver+0x18c/0x2a0 [<000000008538f359>] bus_for_each_drv+0x151/0x1d0 [<0000000038e09747>] __device_attach+0x1c9/0x4e0 [<00000000dd86e533>] bus_probe_device+0x1d5/0x280 [<00000000839bea35>] device_add+0xae0/0x1cb0 [<000000009c2abf46>] new_device_store+0x3b6/0x5f0 [<00000000fb823d7f>] bus_attr_store+0x72/0xa0 [<000000007acc4295>] sysfs_kf_write+0x106/0x160 [<000000005f50cb4d>] kernfs_fop_write_iter+0x3a8/0x5a0 [<0000000075eb41bf>] vfs_write+0x8f0/0xc80

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50510 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/smmuv3: Fix hotplug callback leak in arm_smmu_pmu_init()arm_smmu_pmu_init() won't remove the callback added bycpuhp_setup_state_multi() when platform_driver_register() failed. Removethe callback by cpuhp_remove_multi_state() in fail path.Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:arm-ccn: Prevent hotplug callback leak")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50527 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix size validation for non-exclusive domains (v4)Fix amdgpu_bo_validate_size() to check whether the TTM domain manager for therequested memory exists, else we get a kernel oops when dereferencing "man".v2: Make the patch standalone, i.e. not dependent on local patches.v3: Preserve old behaviour and just check that the manager pointer is not NULL.v4: Complain if GTT domain requested and it is uninitialized--most likely a bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50531 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix an information leak in tipc_topsrv_kern_subscrUse a 8-byte write to initialize sub.usr_handle intipc_topsrv_kern_subscr(), otherwise four bytes remain uninitializedwhen issuing setsockopt(..., SOL_TIPC, ...).This resulted in an infoleak reported by KMSAN when the packet wasreceived: ===================================================== BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/iov_iter.c:169 instrument_copy_to_user ./include/linux/instrumented.h:121 copyout+0xbc/0x100 lib/iov_iter.c:169 _copy_to_iter+0x5c0/0x20a0 lib/iov_iter.c:527 copy_to_iter ./include/linux/uio.h:176 simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419 skb_copy_datagram_iter+0x58/0x200 net/core/datagram.c:527 skb_copy_datagram_msg ./include/linux/skbuff.h:3903 packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469 ____sys_recvmsg+0x2c4/0x810 net/socket.c:? ___sys_recvmsg+0x217/0x840 net/socket.c:2743 __sys_recvmsg net/socket.c:2773 __do_sys_recvmsg net/socket.c:2783 __se_sys_recvmsg net/socket.c:2780 __x64_sys_recvmsg+0x364/0x540 net/socket.c:2780 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 ... Uninit was stored to memory at: tipc_sub_subscribe+0x42d/0xb50 net/tipc/subscr.c:156 tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375 tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579 tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190 tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084 tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201 __sys_setsockopt+0x87f/0xdc0 net/socket.c:2252 __do_sys_setsockopt net/socket.c:2263 __se_sys_setsockopt net/socket.c:2260 __x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 Local variable sub created at: tipc_topsrv_kern_subscr+0x57/0x400 net/tipc/topsrv.c:562 tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190 Bytes 84-87 of 88 are uninitialized Memory access of size 88 starts at ffff88801ed57cd0 Data copied to user address 0000000020000400 ... =====================================================

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50536 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix repeated calls to sock_put() when msg has more_dataIn tcp_bpf_send_verdict() redirection, the eval variable is assigned to__SK_REDIRECT after the apply_bytes data is sent, if msg has more_data,sock_put() will be called multiple times.We should reset the eval variable to __SK_NONE every time more_datastarts.This causes:IPv4: Attempt to release TCP socket in state 1 00000000b4c925d7------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110Modules linked in:CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014Call Trace: __tcp_transmit_skb+0xa1b/0xb90 ? __alloc_skb+0x8c/0x1a0 ? __kmalloc_node_track_caller+0x184/0x320 tcp_write_xmit+0x22a/0x1110 __tcp_push_pending_frames+0x32/0xf0 do_tcp_sendpages+0x62d/0x640 tcp_bpf_push+0xae/0x2c0 tcp_bpf_sendmsg_redir+0x260/0x410 ? preempt_count_add+0x70/0xa0 tcp_bpf_send_verdict+0x386/0x4b0 tcp_bpf_sendmsg+0x21b/0x3b0 sock_sendmsg+0x58/0x70 __sys_sendto+0xfa/0x170 ? xfd_validate_state+0x1d/0x80 ? switch_fpu_return+0x59/0xe0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50550 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-iolatency: Fix memory leak on add_disk() failuresWhen a gendisk is successfully initialized but add_disk() fails such as whena loop device has invalid number of minor device numbers specified,blkcg_init_disk() is called during init and then blkcg_exit_disk() duringerror handling. Unfortunately, iolatency gets initialized in the former butdoesn't get cleaned up in the latter.This is because, in non-error cases, the cleanup is performed bydel_gendisk() calling rq_qos_exit(), the assumption being that rq_qospolicies, iolatency being one of them, can only be activated once the diskis fully registered and visible. That assumption is true for wbt and iocost,but not so for iolatency as it gets initialized before add_disk() is called.It is desirable to lazy-init rq_qos policies because they are optionalfeatures and add to hot path overhead once initialized - each IO has to walkall the registered rq_qos policies. So, we want to switch iolatency to lazyinit too. However, that's a bigger change. As a fix for the immediateproblem, let's just add an extra call to rq_qos_exit() in blkcg_exit_disk().This is safe because duplicate calls to rq_qos_exit() become noop's.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50555 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix a null-ptr-deref in tipc_topsrv_acceptsyzbot found a crash in tipc_topsrv_accept: KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] Workqueue: tipc_rcv tipc_topsrv_accept RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487 Call Trace: tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306It was caused by srv->listener that might be set to null bytipc_topsrv_stop() in net .exit whereas it's still used intipc_topsrv_accept() worker.srv->listener is protected by srv->idr_lock in tipc_topsrv_stop(), so adda check for srv->listener under srv->idr_lock in tipc_topsrv_accept() toavoid the null-ptr-deref. To ensure the lsock is not released during thetipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop()where it's waiting until the tipc_topsrv_accept worker to be done.Note that sk_callback_lock is used to protect sk->sk_user_data instead ofsrv->listener, and it should check srv in tipc_topsrv_listener_data_ready()instead. This also ensures that no more tipc_topsrv_accept worker will bestarted after tipc_conn_close() is called in tipc_topsrv_stop() where itsets sk->sk_user_data to null.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50624 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: netsec: fix error handling in netsec_register_mdio()If phy_device_register() fails, phy_device_free() need be called toput refcount, so memory of phy device and device name can be freedin callback function.If get_phy_device() fails, mdiobus_unregister() need be called,or it will cause warning in mdiobus_free() and kobject is leaked.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50628 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/gud: Fix UBSAN warningUBSAN complains about invalid value for bool:[ 101.165172] [drm] Initialized gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1[ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer device[ 101.213426] usbcore: registered new interface driver gud[ 101.989431] ================================================================================[ 101.989441] UBSAN: invalid-load in linux/include/linux/iosys-map.h:253:9[ 101.989447] load of value 121 is not a valid value for type '_Bool'[ 101.989451] CPU: 1 PID: 455 Comm: kworker/1:6 Not tainted 5.18.0-rc5-gud-5.18-rc5 #3[ 101.989456] Hardware name: Hewlett-Packard HP EliteBook 820 G1/1991, BIOS L71 Ver. 01.44 04/12/2018[ 101.989459] Workqueue: events_long gud_flush_work [gud][ 101.989471] Call Trace:[ 101.989474] [ 101.989479] dump_stack_lvl+0x49/0x5f[ 101.989488] dump_stack+0x10/0x12[ 101.989493] ubsan_epilogue+0x9/0x3b[ 101.989498] __ubsan_handle_load_invalid_value.cold+0x44/0x49[ 101.989504] dma_buf_vmap.cold+0x38/0x3d[ 101.989511] ? find_busiest_group+0x48/0x300[ 101.989520] drm_gem_shmem_vmap+0x76/0x1b0 [drm_shmem_helper][ 101.989528] drm_gem_shmem_object_vmap+0x9/0xb [drm_shmem_helper][ 101.989535] drm_gem_vmap+0x26/0x60 [drm][ 101.989594] drm_gem_fb_vmap+0x47/0x150 [drm_kms_helper][ 101.989630] gud_prep_flush+0xc1/0x710 [gud][ 101.989639] ? _raw_spin_lock+0x17/0x40[ 101.989648] gud_flush_work+0x1e0/0x430 [gud][ 101.989653] ? __switch_to+0x11d/0x470[ 101.989664] process_one_work+0x21f/0x3f0[ 101.989673] worker_thread+0x200/0x3e0[ 101.989679] ? rescuer_thread+0x390/0x390[ 101.989684] kthread+0xfd/0x130[ 101.989690] ? kthread_complete_and_exit+0x20/0x20[ 101.989696] ret_from_fork+0x22/0x30[ 101.989706] [ 101.989708] ================================================================================The source of this warning is in iosys_map_clear() called fromdma_buf_vmap(). It conditionally sets values based on map->is_iomem. Theiosys_map variables are allocated uninitialized on the stack leading to->is_iomem having all kinds of values and not only 0/1.Fix this by zeroing the iosys_map variables.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50634 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:power: supply: cw2015: Fix potential null-ptr-deref in cw_bat_probe()cw_bat_probe() calls create_singlethread_workqueue() and not checked theret value, which may return NULL. And a null-ptr-deref may happen:cw_bat_probe() create_singlethread_workqueue() # failed, cw_bat->wq is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-derefCheck the ret value and return -ENOMEM if it is NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50655 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: associate skb with a device at txSyzkaller triggered flow dissector warning with the following:r0 = openat$ppp(0xffffffffffffff9c, &(0x7f0000000000), 0xc0802, 0x0)ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &(0x7f00000000c0))ioctl$PPPIOCSACTIVE(r0, 0x40107446, &(0x7f0000000240)={0x2, &(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})pwritev(r0, &(0x7f0000000040)=[{&(0x7f0000000140)='\x00!', 0x2}], 0x1, 0x0, 0x0)[ 9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0[ 9.485929] skb_get_poff+0x53/0xa0[ 9.485937] bpf_skb_get_pay_offset+0xe/0x20[ 9.485944] ? ppp_send_frame+0xc2/0x5b0[ 9.485949] ? _raw_spin_unlock_irqrestore+0x40/0x60[ 9.485958] ? __ppp_xmit_process+0x7a/0xe0[ 9.485968] ? ppp_xmit_process+0x5b/0xb0[ 9.485974] ? ppp_write+0x12a/0x190[ 9.485981] ? do_iter_write+0x18e/0x2d0[ 9.485987] ? __import_iovec+0x30/0x130[ 9.485997] ? do_pwritev+0x1b6/0x240[ 9.486016] ? trace_hardirqs_on+0x47/0x50[ 9.486023] ? __x64_sys_pwritev+0x24/0x30[ 9.486026] ? do_syscall_64+0x3d/0x80[ 9.486031] ? entry_SYSCALL_64_after_hwframe+0x63/0xcdFlow dissector tries to find skb net namespace either via deviceor via socket. Neigher is set in ppp_send_frame, so let's manuallyuse ppp->dev.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50676 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: rds: don't hold sock lock when cancelling work from rds_tcp_reset_callbacks()syzbot is reporting lockdep warning at rds_tcp_reset_callbacks() [1], forcommit ac3615e7f3cffe2a ("RDS: TCP: Reduce code duplication inrds_tcp_reset_callbacks()") added cancel_delayed_work_sync() into a sectionprotected by lock_sock() without realizing that rds_send_xmit() might calllock_sock().We don't need to protect cancel_delayed_work_sync() using lock_sock(), foreven if rds_{send,recv}_worker() re-queued this work while __flush_work() from cancel_delayed_work_sync() was waiting for this work to complete,retried rds_{send,recv}_worker() is no-op due to the absence of RDS_CONN_UPbit.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50734 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvmem: core: Fix memleak in nvmem_register()dev_set_name will alloc memory for nvmem->dev.kobj.name innvmem_register, when nvmem_validate_keepouts failed, nvmem'smemory will be freed and return, but nobody will free memoryfor nvmem->dev.kobj.name, there will be memleak, so movingnvmem_validate_keepouts() after device_register() and letthe device core deal with cleaning name in error cases.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50741 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Disable useless interrupt to avoid kernel panicThere is a hardware bug that the interrupt STMBUF_HALF may be triggeredafter or when disable interrupt.It may led to unexpected kernel panic.And interrupt STMBUF_HALF and STMBUF_RTND have no other effect.So disable them and the unused interrupts.meanwhile clear the interrupt status when disable interrupt.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50766 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set generation before calling btrfs_clean_tree_block in btrfs_init_new_buffersyzbot is reporting uninit-value in btrfs_clean_tree_block() [1], forcommit bc877d285ca3dba2 ("btrfs: Deduplicate extent_buffer init code")missed that btrfs_set_header_generation() in btrfs_init_new_buffer() mustnot be moved to after clean_tree_block() because clean_tree_block() iscalling btrfs_header_generation() since commit 55c69072d6bd5be1 ("Btrfs:Fix extent_buffer usage when nodesize != leafsize").Since memzero_extent_buffer() will reset "struct btrfs_header" part, wecan't move btrfs_set_header_generation() to before memzero_extent_buffer().Just re-add btrfs_set_header_generation() before btrfs_clean_tree_block().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50771 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Fix __this_cpu_read() lockdep warning in rcu_force_quiescent_state()Running rcutorture with non-zero fqs_duration module parameter in akernel built with CONFIG_PREEMPTION=y results in the following splat:BUG: using __this_cpu_read() in preemptible [00000000]code: rcu_torture_fqs/398caller is __this_cpu_preempt_check+0x13/0x20CPU: 3 PID: 398 Comm: rcu_torture_fqs Not tainted 6.0.0-rc1-yoctodev-standard+Call Trace:dump_stack_lvl+0x5b/0x86dump_stack+0x10/0x16check_preemption_disabled+0xe5/0xf0__this_cpu_preempt_check+0x13/0x20rcu_force_quiescent_state.part.0+0x1c/0x170rcu_force_quiescent_state+0x1e/0x30rcu_torture_fqs+0xca/0x160? rcu_torture_boost+0x430/0x430kthread+0x192/0x1d0? kthread_complete_and_exit+0x30/0x30ret_from_fork+0x22/0x30The problem is that rcu_force_quiescent_state() uses __this_cpu_read()in preemptible code instead of the proper raw_cpu_read(). This committherefore changes __this_cpu_read() to raw_cpu_read().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50786 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: s5p-mfc: Clear workbit to handle error conditionDuring error on CLOSE_INSTANCE command, ctx_work_bits was not gettingcleared. During consequent mfc execution NULL pointer dereferencing ofthis context led to kernel panic. This patch fixes this issue by makingsure to clear ctx_work_bits always.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50811 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: fix missing unmap if z_erofs_get_extent_compressedlen() failsOtherwise, meta buffers could be leaked.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50820 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/arm_dmc620: Fix hotplug callback leak in dmc620_pmu_init()dmc620_pmu_init() won't remove the callback added bycpuhp_setup_state_multi() when platform_driver_register() failed. Removethe callback by cpuhp_remove_multi_state() in fail path.Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:arm-ccn: Prevent hotplug callback leak")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50838 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: stream: purge sk_error_queue in sk_stream_kill_queues()Changheon Lee reported TCP socket leaks, with a nice repro.It seems we leak TCP sockets with the following sequence:1) SOF_TIMESTAMPING_TX_ACK is enabled on the socket. Each ACK will cook an skb put in error queue, from __skb_tstamp_tx(). __skb_tstamp_tx() is using skb_clone(), unless SOF_TIMESTAMPING_OPT_TSONLY was also requested.2) If the application is also using MSG_ZEROCOPY, then we put in the error queue cloned skbs that had a struct ubuf_info attached to them. Whenever an struct ubuf_info is allocated, sock_zerocopy_alloc() does a sock_hold(). As long as the cloned skbs are still in sk_error_queue, socket refcount is kept elevated.3) Application closes the socket, while error queue is not empty.Since tcp_close() no longer purges the socket error queue,we might end up with a TCP socket with at least one skb inerror queue keeping the socket alive forever.This bug can be (ab)used to consume all kernel memoryand freeze the host.We need to purge the error queue, with proper synchronizationagainst concurrent writers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50854 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: virtual_ncidev: Fix memory leak in virtual_nci_send()skb should be free in virtual_nci_send(), otherwise kmemleak will reportmemleak.Steps for reproduction (simulated in qemu): cd tools/testing/selftests/nci make ./nci_devBUG: memory leakunreferenced object 0xffff888107588000 (size 208): comm "nci_dev", pid 206, jiffies 4294945376 (age 368.248s) 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 00 00 00 00 00 00 00 ................ backtrace: [<000000008d94c8fd>] __alloc_skb+0x1da/0x290 [<00000000278bc7f8>] nci_send_cmd+0xa3/0x350 [<0000000081256a22>] nci_reset_req+0x6b/0xa0 [<000000009e721112>] __nci_request+0x90/0x250 [<000000005d556e59>] nci_dev_up+0x217/0x5b0 [<00000000e618ce62>] nfc_dev_up+0x114/0x220 [<00000000981e226b>] nfc_genl_dev_up+0x94/0xe0 [<000000009bb03517>] genl_family_rcv_msg_doit.isra.14+0x228/0x2d0 [<00000000b7f8c101>] genl_rcv_msg+0x35c/0x640 [<00000000c94075ff>] netlink_rcv_skb+0x11e/0x350 [<00000000440cfb1e>] genl_rcv+0x24/0x40 [<0000000062593b40>] netlink_unicast+0x43f/0x640 [<000000001d0b13cc>] netlink_sendmsg+0x73a/0xbf0 [<000000003272487f>] __sys_sendto+0x324/0x370 [<00000000ef9f1747>] __x64_sys_sendto+0xdd/0x1b0 [<000000001e437841>] do_syscall_64+0x3f/0x90

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50865 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix a signed-integer-overflow bug in tcp_add_backlog()The type of sk_rcvbuf and sk_sndbuf in struct sock is int, andin tcp_add_backlog(), the variable limit is caculated by addingsk_rcvbuf, sk_sndbuf and 64 * 1024, it may exceed the max valueof int and overflow. This patch reduces the limit budget byhalving the sndbuf to solve this issue since ACK packets are muchsmaller than the payload.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50871 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: Fix qmi_msg_handler data structure initializationqmi_msg_handler is required to be null terminated by QMI module.There might be a case where a handler for a msg id is not present in thehandlers array which can lead to infinite loop while searching the handlerand therefore out of bound access in qmi_invoke_handler().Hence update the initialization in qmi_msg_handler data structure.Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50875 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:of: overlay: fix null pointer dereferencing in find_dup_cset_node_entry() and find_dup_cset_prop()When kmalloc() fail to allocate memory in kasprintf(), fn_1 or fn_2 willbe NULL, and strcmp() will cause null pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2022-50877 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: broadcom: bcm4908_enet: update TX stats after actual transmissionQueueing packets doesn't guarantee their transmission. Update TX statsafter hardware confirms consuming submitted data.This also fixes a possible race and NULL dereference.bcm4908_enet_start_xmit() could try to access skb after freeing it inthe bcm4908_enet_poll_tx().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52486 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm: Don't unref the same fb many times by mistake due to deadlock handlingIf we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()we proceed to unref the fb and then retry the whole thing from the top.But we forget to reset the fb pointer back to NULL, and so if we thenget another error during the retry, before the fb lookup, we proceedthe unref the same fb again without having gotten another reference.The end result is that the fb will (eventually) end up being freedwhile it's still in use.Reset fb to NULL once we've unreffed it to avoid doing it againuntil we've done another fb lookup.This turned out to be pretty easy to hit on a DG2 when doing asyncflips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom Isaw that drm_closefb() simply got stuck in a busy loop while walkingthe framebuffer list. Fortunately I was able to convince it to oopsinstead, and from there it was easier to track down the culprit.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52488 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFOThe SC16IS7XX IC supports a burst mode to access the FIFOs where theinitial register address is sent ($00), followed by all the FIFO datawithout having to resend the register address each time. In this mode, theIC doesn't increment the register address for each R/W byte.The regmap_raw_read() and regmap_raw_write() are functions which canperform IO over multiple registers. They are currently used to read/writefrom/to the FIFO, and although they operate correctly in this burst mode onthe SPI bus, they would corrupt the regmap cache if it was not disabledmanually. The reason is that when the R/W size is more than 1 byte, thesefunctions assume that the register address is incremented and handle thecache accordingly.Convert FIFO R/W functions to use the regmap _noinc_ versions in order toremove the manual cache control which was a workaround when using the_raw_ versions. FIFO registers are properly declared as volatile socache will not be used/updated for FIFO accesses.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52498 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PM: sleep: Fix possible deadlocks in core system-wide PM codeIt is reported that in low-memory situations the system-wide resume corecode deadlocks, because async_schedule_dev() executes its argumentfunction synchronously if it cannot allocate memory (and not only inthat case) and that function attempts to acquire a mutex that is alreadyheld. Executing the argument function synchronously from withindpm_async_fn() may also be problematic for ordering reasons (it maycause a consumer device's resume callback to be invoked before arequisite supplier device's one, for example).Address this by changing the code in question to useasync_schedule_dev_nocall() for scheduling the asynchronousexecution of device suspend and resume functions and to directlyrun them synchronously if async_schedule_dev_nocall() returns false.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52522 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix possible store tearing in neigh_periodic_work()While looking at a related syzbot report involving neigh_periodic_work(),I found that I forgot to add an annotation when deleting anRCU protected item from a list.Readers use rcu_deference(*np), we need to use eitherrcu_assign_pointer() or WRITE_ONCE() on writer sideto prevent store tearing.I use rcu_assign_pointer() to have lockdep support,this was the choice made in neigh_flush_dev().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52527 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()Including the transhdrlen in length is a problem when the packet ispartially filled (e.g. something like send(MSG_MORE) happened previously)when appending to an IPv4 or IPv6 packet as we don't want to repeat thetransport header or account for it twice. This can happen under somecircumstances, such as splicing into an L2TP socket.The symptom observed is a warning in __ip6_append_data(): WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800that occurs when MSG_SPLICE_PAGES is used to append more data to an alreadypartially occupied skbuff. The warning occurs when 'copy' is larger thanthe amount of data in the message iterator. This is because the requestedlength includes the transport header length when it shouldn't. This can betriggered by, for example: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); bind(sfd, ...); // ::1 connect(sfd, ...); // ::1 port 7 send(sfd, buffer, 4100, MSG_MORE); sendfile(sfd, dfd, NULL, 1024);Fix this by only adding transhdrlen into the length if the write queue isempty in l2tp_ip6_sendmsg(), analogously to how UDP does things.l2tp_ip_sendmsg() looks like it won't suffer from this problem as it buildsthe UDP packet itself.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52561 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reservedAdding a reserved memory region for the framebuffer memory(the splash memory region set up by the bootloader).It fixes a kernel panic (arm-smmu: Unhandled context faultat this particular memory region) reported on DB845c runningv5.10.y.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52573 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: rds: Fix possible NULL-pointer dereferenceIn rds_rdma_cm_event_handler_cmn() check, if conn pointer existsbefore dereferencing it as rdma_set_service_type() argumentFound by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52580 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/core: Fix ETH_P_1588 flow dissectorWhen a PTP ethernet raw frame with a size of more than 256 bytes followedby a 0xff pattern is sent to __skb_flow_dissect, nhoff value calculationis wrong. For example: hdr->message_length takes the wrong value (0xffff)and it does not replicate real header length. In this case, 'nhoff' valuewas overridden and the PTP header was badly dissected. This leads to akernel crash.net/core: flow_dissectornet/core flow dissector nhoff = 0x0000000enet/core flow dissector hdr->message_length = 0x0000ffffnet/core flow dissector nhoff = 0x0001000d (u16 overflow)...skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88skb frag: 00000000: f7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffUsing the size of the ptp_header struct will allow the correctedcalculation of the nhoff value.net/core flow dissector nhoff = 0x0000000enet/core flow dissector nhoff = 0x00000030 (sizeof ptp_header)...skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 f7 ff ffskb linear: 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffskb linear: 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffskb frag: 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffKernel trace:[ 74.984279] ------------[ cut here ]------------[ 74.989471] kernel BUG at include/linux/skbuff.h:2440![ 74.995237] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI[ 75.001098] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 5.15.85-intel-ese-standard-lts #1[ 75.011629] Hardware name: Intel Corporation A-Island (CPU:AlderLake)/A-Island (ID:06), BIOS SB_ADLP.01.01.00.01.03.008.D-6A9D9E73-dirty Mar 30 2023[ 75.026507] RIP: 0010:eth_type_trans+0xd0/0x130[ 75.031594] Code: 03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb ab <0f> 0b b8 00 01 00 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9[ 75.052612] RSP: 0018:ffff9948c0228de0 EFLAGS: 00010297[ 75.058473] RAX: 00000000000003f2 RBX: ffff8e47047dc300 RCX: 0000000000001003[ 75.066462] RDX: ffff8e4e8c9ea040 RSI: ffff8e4704e0a000 RDI: ffff8e47047dc300[ 75.074458] RBP: ffff8e4704e2acc0 R08: 00000000000003f3 R09: 0000000000000800[ 75.082466] R10: 000000000000000d R11: ffff9948c0228dec R12: ffff8e4715e4e010[ 75.090461] R13: ffff9948c0545018 R14: 0000000000000001 R15: 0000000000000800[ 75.098464] FS: 0000000000000000(0000) GS:ffff8e4e8fb00000(0000) knlGS:0000000000000000[ 75.107530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 75.113982] CR2: 00007f5eb35934a0 CR3: 0000000150e0a002 CR4: 0000000000770ee0[ 75.121980] PKRU: 55555554[ 75.125035] Call Trace:[ 75.127792] [ 75.130063] ? eth_get_headlen+0xa4/0xc0[ 75.134472] igc_process_skb_fields+0xcd/0x150[ 75.139461] igc_poll+0xc80/0x17b0[ 75.143272] __napi_poll+0x27/0x170[ 75.147192] net_rx_action+0x234/0x280[ 75.151409] __do_softirq+0xef/0x2f4[ 75.155424] irq_exit_rcu+0xc7/0x110[ 75.159432] common_interrupt+0xb8/0xd0[ 75.163748] [ 75.166112] [ 75.168473] asm_common_interrupt+0x22/0x40[ 75.173175] RIP: 0010:cpuidle_enter_state+0xe2/0x350[ 75.178749] Code: 85 c0 0f 8f 04 02 00 00 31 ff e8 39 6c 67 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 50 02 00 00 31 ff e8 52 b0 6d ff fb 45 85 f6 <0f> 88 b1 00 00 00 49 63 ce 4c 2b 2c 24 48 89 c8 48 6b d1 68 48 c1[ 75.199757] RSP: 0018:ffff9948c013bea8 EFLAGS: 00000202[ 75.205614] RAX: ffff8e4e8fb00000 RBX: ffffb948bfd23900 RCX: 000000000000001f[ 75.213619] RDX: 0000000000000004 RSI: ffffffff94206161 RDI: ffffffff94212e20[ 75.221620] RBP: 0000000000000004 R08: 000000117568973a R09: 0000000000000001[ 75.229622] R10: 000000000000afc8 R11: ffff8e4e8fb29ce4 R12: ffffffff945ae980[ 75.237628] R13: 000000117568973a R14: 0000000000000004 R15: 0000000000000000[ 75.245635] ? ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52581 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix memleak when more than 255 elements expiredWhen more than 255 elements expired we're supposed to switch to a new gccontainer structure.This never happens: u8 type will wrap before reaching the boundaryand nft_trans_gc_space() always returns true.This means we recycle the initial gc container structure andlose track of the elements that came before.While at it, don't deref 'gc' after we've passed it to call_rcu.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52598 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/ptrace: handle setting of fpc register correctlyIf the content of the floating point control (fpc) register of a tracedprocess is modified with the ptrace interface the new value is tested forvalidity by temporarily loading it into the fpc register.This may lead to corruption of the fpc register of the tracing process:if an interrupt happens while the value is temporarily loaded into thefpc register, and within interrupt context floating point or vectorregisters are used, the current fp/vx registers are saved withsave_fpu_regs() assuming they belong to user space and will be loaded intofp/vx registers when returning to user space.test_fp_ctl() restores the original user space fpc register value, howeverit will be discarded, when returning to user space.In result the tracer will incorrectly continue to run with the value thatwas supposed to be used for the traced process.Fix this by saving fpu register contents with save_fpu_regs() before usingtest_fp_ctl().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52606 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/lib: Validate size for vector operationsSome of the fp/vmx code in sstep.c assume a certain maximum size for theinstructions being emulated. The size of those operations however isdetermined separately in analyse_instr().Add a check to validate the assumption on the maximum size of theoperations, so as to prevent any unintended kernel stack corruption.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52608 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scmi: Check mailbox/SMT channel for consistencyOn reception of a completion interrupt the shared memory area is accessedto retrieve the message header at first and then, if the message sequencenumber identifies a transaction which is still pending, the relatedpayload is fetched too.When an SCMI command times out the channel ownership remains with theplatform until eventually a late reply is received and, as a consequence,any further transmission attempt remains pending, waiting for the channelto be relinquished by the platform.Once that late reply is received the channel ownership is given backto the agent and any pending request is then allowed to proceed andoverwrite the SMT area of the just delivered late reply; then the waitfor the reply to the new request starts.It has been observed that the spurious IRQ related to the late reply canbe wrongly associated with the freshly enqueued request: when that happensthe SCMI stack in-flight lookup procedure is fooled by the fact that themessage header now present in the SMT area is related to the new pendingtransaction, even though the real reply has still to arrive.This race-condition on the A2P channel can be detected by looking at thechannel status bits: a genuine reply from the platform will have set thechannel free bit before triggering the completion IRQ.Add a consistency check to validate such condition in the A2P ISR.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52610 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_ct: fix skb leak and crash on ooo fragsact_ct adds skb->users before defragmentation. If frags arrive in order,the last frag's reference is reset in: inet_frag_reasm_prepare skb_morphwhich is not straightforward.However when frags arrive out of order, nobody unref the last frag, andall frags are leaked. The situation is even worse, as initiating packetcapture can lead to a crash[0] when skb has been cloned and shared at thesame time.Fix the issue by removing skb_get() before defragmentation. act_ctreturns TC_ACT_CONSUMED when defrag failed or in progress.[0]:[ 843.804823] ------------[ cut here ]------------[ 843.809659] kernel BUG at net/core/skbuff.c:2091![ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP[ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2[ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022[ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300[ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89[ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202[ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820[ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00[ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000[ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880[ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900[ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000[ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0[ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 843.894229] PKRU: 55555554[ 843.898539] Call Trace:[ 843.902772] [ 843.906922] ? __die_body+0x1e/0x60[ 843.911032] ? die+0x3c/0x60[ 843.915037] ? do_trap+0xe2/0x110[ 843.918911] ? pskb_expand_head+0x2ac/0x300[ 843.922687] ? do_error_trap+0x65/0x80[ 843.926342] ? pskb_expand_head+0x2ac/0x300[ 843.929905] ? exc_invalid_op+0x50/0x60[ 843.933398] ? pskb_expand_head+0x2ac/0x300[ 843.936835] ? asm_exc_invalid_op+0x1a/0x20[ 843.940226] ? pskb_expand_head+0x2ac/0x300[ 843.943580] inet_frag_reasm_prepare+0xd1/0x240[ 843.946904] ip_defrag+0x5d4/0x870[ 843.950132] nf_ct_handle_fragments+0xec/0x130 [nf_conntrack][ 843.953334] tcf_ct_act+0x252/0xd90 [act_ct][ 843.956473] ? tcf_mirred_act+0x516/0x5a0 [act_mirred][ 843.959657] tcf_action_exec+0xa1/0x160[ 843.962823] fl_classify+0x1db/0x1f0 [cls_flower][ 843.966010] ? skb_clone+0x53/0xc0[ 843.969173] tcf_classify+0x24d/0x420[ 843.972333] tc_run+0x8f/0xf0[ 843.975465] __netif_receive_skb_core+0x67a/0x1080[ 843.978634] ? dev_gro_receive+0x249/0x730[ 843.981759] __netif_receive_skb_list_core+0x12d/0x260[ 843.984869] netif_receive_skb_list_internal+0x1cb/0x2f0[ 843.987957] ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core][ 843.991170] napi_complete_done+0x72/0x1a0[ 843.994305] mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core][ 843.997501] __napi_poll+0x25/0x1b0[ 844.000627] net_rx_action+0x256/0x330[ 844.003705] __do_softirq+0xb3/0x29b[ 844.006718] irq_exit_rcu+0x9e/0xc0[ 844.009672] common_interrupt+0x86/0xa0[ 844.012537] [ 844.015285] [ 844.017937] asm_common_interrupt+0x26/0x40[ 844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20[ 844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52623 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: Fix a suspicious RCU usage warningI received the following warning while running cthon against an ontapserver running pNFS:[ 57.202521] =============================[ 57.202522] WARNING: suspicious RCU usage[ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted[ 57.202525] -----------------------------[ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!![ 57.202527] other info that might help us debug this:[ 57.202528] rcu_scheduler_active = 2, debug_locks = 1[ 57.202529] no locks held by test5/3567.[ 57.202530] stack backtrace:[ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e[ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022[ 57.202536] Call Trace:[ 57.202537] [ 57.202540] dump_stack_lvl+0x77/0xb0[ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0[ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202671] ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a][ 57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a][ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202866] write_cache_pages+0x265/0x450[ 57.202870] ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202913] do_writepages+0xd2/0x230[ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80[ 57.202921] filemap_fdatawrite_wbc+0x67/0x80[ 57.202924] filemap_write_and_wait_range+0xd9/0x170[ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202969] __se_sys_close+0x46/0xd0[ 57.202972] do_syscall_64+0x68/0x100[ 57.202975] ? do_syscall_64+0x77/0x100[ 57.202976] ? do_syscall_64+0x77/0x100[ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76[ 57.202982] RIP: 0033:0x7fe2b12e4a94[ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3[ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003[ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94[ 57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003[ 57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49[ 57.202993] R10: 00007f---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52627 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: adc: ad7091r: Allow users to configure device eventsAD7091R-5 devices are supported by the ad7091r-5 driver together withthe ad7091r-base driver. Those drivers declared iio events for notifyinguser space when ADC readings fall bellow the thresholds of low limitregisters or above the values set in high limit registers.However, to configure iio events and their thresholds, a set of callbackfunctions must be implemented and those were not present until now.The consequence of trying to configure ad7091r-5 events without theproper callback functions was a null pointer dereference in the kernelbecause the pointers to the callback functions were not set.Implement event configuration callbacks allowing users to read/writeevent thresholds and enable/disable event generation.Since the event spec structs are generic to AD7091R devices, also movethose from the ad7091r-5 driver the base driver so they can be reusedwhen support for ad7091r-2/-4/-8 be added.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52632 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix lock dependency warning with srcu======================================================WARNING: possible circular locking dependency detected6.5.0-kfd-yangp #2289 Not tainted------------------------------------------------------kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0-> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0-> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80-> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0other info that might help us debug this:Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work)Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu);

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52638 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: j1939: prevent deadlock by changing j1939_socks_lock to rwlockThe following 3 locks would race against each other, causing thedeadlock situation in the Syzbot bug report:- j1939_socks_lock- active_session_list_lock- sk_session_queue_lockA reasonable fix is to change j1939_socks_lock to an rwlock, since inthe rare situations where a write lock is required for the linked listthat j1939_socks_lock is protecting, the code does not attempt toacquire any more locks. This would break the circular lock dependency,where, for example, the current thread already locks j1939_socks_lockand attempts to acquire sk_session_queue_lock, and at the same time,another thread attempts to acquire j1939_socks_lock while holdingsk_session_queue_lock.NOTE: This patch along does not fix the unregister_netdevice bugreported by Syzbot; instead, it solves a deadlock situation to preparefor one or more further patches to actually fix the Syzbot bug, whichappears to be a reference counting problem within the j1939 codebase.[mkl: remove unrelated newline change]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52642 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: rc: bpf attach/detach requires write permissionNote that bpf attach/detach also requires CAP_NET_ADMIN.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52644 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabledWhen QoS is disabled, the queue priority value will not map to the correctieee80211 queue since there is only one queue. Stop/wake queue 0 when QoSis disabled to prevent trying to stop/wake a non-existent queue and failingto stop/wake the actual queue instantiated.Log of issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3 [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52645 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: mediatek: fix race conditions with genpdIf the power domains are registered first with genpd and *after that*the driver attempts to power them on in the probe sequence, then it ispossible that a race condition occurs if genpd tries to power them onin the same time.The same is valid for powering them off before unregistering themfrom genpd.Attempt to fix race conditions by first removing the domains from genpdand *after that* powering down domains.Also first power up the domains and *after that* register themto genpd.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52646 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:aio: fix mremap after fork null-derefCommit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduceda null-deref if mremap is called on an old aio mapping after fork asmm->ioctx_table will be set to NULL.[jmoyer@redhat.com: fix 80 column issue]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52664 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: atlantic: eliminate double free in error handling logicDriver has a logic leak in ring data allocation/free,where aq_ring_free could be called multiple times on same ring,if system is under stress and got memory allocation error.Ring pointer was used as an indicator of failure, but this isnot correct since only ring data is allocated/deallocated.Ring itself is an array member.Changing ring allocation functions to return error code directly.This simplifies error handling and eliminates aq_ring_freeon higher layer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52669 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: s390/aes - Fix buffer overread in CTR modeWhen processing the last block, the s390 ctr code will always reada whole block, even if there isn't a whole block of data left. Fixthis by using the actual length left and copy it into a buffer firstfor processing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52672 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pipe: wakeup wr_wait after setting max_usageCommit c73be61cede5 ("pipe: Add general notification queue support") aregression was introduced that would lock up resized pipes under certainconditions. See the reproducer in [1].The commit resizing the pipe ring size was moved to a differentfunction, doing that moved the wakeup for pipe->wr_wait before actuallyraising pipe->max_usage. If a pipe was full before the resize occured itwould result in the wakeup never actually triggering pipe_write.Set @max_usage and @nr_accounted before waking writers if this isn't awatch queue.[Christian Brauner : rewrite to account for watch queues]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52674 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 andSCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outsidescarlett2_mixer_values[].

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52679 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:of: Fix double free in of_parse_phandle_with_args_mapIn of_parse_phandle_with_args_map() the inner loop thatiterates through the map entries calls of_node_put(new)to free the reference acquired by the previous iterationof the inner loop. This assumes that the value of "new" isNULL on the first iteration of the inner loop.Make sure that this is true in all iterations of the outerloop by setting "new" to NULL after its value is assigned to "cur".Extend the unittest to detect the double free and add an additionaltest case that actually triggers this path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52680 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: scarlett2: Add missing error checks to *_ctl_get()The *_ctl_get() functions which call scarlett2_update_*() were notchecking the return value. Fix to check the return value and pass tothe caller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52683 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: LPIT: Avoid u32 multiplication overflowIn lpit_update_residency() there is a possibility of overflowin multiplication, if tsc_khz is large enough (> UINT_MAX/1000).Change multiplication to mul_u32_u32().Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52685 Severity: Moderate CVSS3 score: 5.5

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

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52691 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix a double-free in si_dpm_initWhen the allocation ofadev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,amdgpu_free_extended_power_table is called to free some fields of adev.However, when the control flow returns to si_dpm_sw_init, it goes tolabel dpm_failed and calls si_dpm_fini, which callsamdgpu_free_extended_power_table again and free those fields again. Thusa double-free is triggered.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52692 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: scarlett2: Add missing error check to scarlett2_usb_set_config()scarlett2_usb_set_config() calls scarlett2_usb_get() but was notchecking the result. Return the error if it fails rather thancontinuing with an invalid value.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52693 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: video: check for error while searching for backlight device parentIf acpi_get_parent() called in acpi_video_dev_register_backlight()fails, for example, because acpi_ut_acquire_mutex() fails insideacpi_get_parent), this can lead to incorrect (uninitialized)acpi_parent handle being passed to acpi_get_pci_dev() for detectingthe parent pci device.Check acpi_get_parent() result and set parent device only in case of success.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52694 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/bridge: tpd12s015: Drop buggy __exit annotation for remove functionWith tpd12s015_remove() marked with __exit this function is discardedwhen the driver is compiled as a built-in. The result is that when thedriver unbinds there is no cleanup done which results in resourceleakage or worse.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52705 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix underflow in second superblock position calculationsMacro NILFS_SB2_OFFSET_BYTES, which computes the position of the secondsuperblock, underflows when the argument device size is less than 4096bytes. Therefore, when using this macro, it is necessary to check inadvance that the device size is not less than a lower limit, or at leastthat underflow does not occur.The current nilfs2 implementation lacks this check, causing out-of-boundblock access when mounting devices smaller than 4096 bytes: I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 NILFS (loop0): unable to read secondary superblock (blocksize = 1024)In addition, when trying to resize the filesystem to a size below 4096bytes, this underflow occurs in nilfs_resize_fs(), passing a huge numberof segments to nilfs_sufile_resize(), corrupting parameters such as thenumber of segments in superblocks. This causes excessive loop iterationsin nilfs_sufile_resize() during a subsequent resize ioctl, causingsemaphore ns_segctor_sem to block for a long time and hang the writerthread: INFO: task segctord:5067 blocked for more than 143 seconds. Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:segctord state:D stack:23456 pid:5067 ppid:2 flags:0x00004000 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x1409/0x43f0 kernel/sched/core.c:6606 schedule+0xc3/0x190 kernel/sched/core.c:6682 rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190 nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline] nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570 kthread+0x270/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 ... Call Trace: folio_mark_accessed+0x51c/0xf00 mm/swap.c:515 __nilfs_get_page_block fs/nilfs2/page.c:42 [inline] nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61 nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121 nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176 nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251 nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline] nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline] nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777 nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422 nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline] nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301 ...This fixes these issues by inserting appropriate minimum device sizechecks or anti-underflow checks, depending on where the macro is used.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52735 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itselfsock_map proto callbacks should never call themselves by design. Protectagainst bugs like [1] and break out of the recursive loop to avoid a stackoverflow in favor of a resource leak.[1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52750 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newerPrior to LLVM 15.0.0, LLVM's integrated assembler would incorrectlybyte-swap NOP when compiling for big-endian, and the resulting series ofbytes happened to match the encoding of FNMADD S21, S30, S0, S0.This went unnoticed until commit: 34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")Prior to that commit, the kernel would always enable the use of FPSIMDearly in boot when __cpu_setup() initialized CPACR_EL1, and so usage ofFNMADD within the kernel was not detected, but could result in thecorruption of user or kernel FPSIMD state.After that commit, the instructions happen to trap during boot prior toFPSIMD being detected and enabled, e.g.| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1| Hardware name: linux,dummy-virt (DT)| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)| pc : __pi_strcmp+0x1c/0x150| lr : populate_properties+0xe4/0x254| sp : ffffd014173d3ad0| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8| Kernel panic - not syncing: Unhandled exception| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1| Hardware name: linux,dummy-virt (DT)| Call trace:| dump_backtrace+0xec/0x108| show_stack+0x18/0x2c| dump_stack_lvl+0x50/0x68| dump_stack+0x18/0x24| panic+0x13c/0x340| el1t_64_irq_handler+0x0/0x1c| el1_abort+0x0/0x5c| el1h_64_sync+0x64/0x68| __pi_strcmp+0x1c/0x150| unflatten_dt_nodes+0x1e8/0x2d8| __unflatten_device_tree+0x5c/0x15c| unflatten_device_tree+0x38/0x50| setup_arch+0x164/0x1e0| start_kernel+0x64/0x38c| __primary_switched+0xbc/0xc4Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which iseither GNU as or LLVM's IAS 15.0.0 and newer, which contains the linkedcommit.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52751 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free in smb2_query_info_compound()The following UAF was triggered when running fstests generic/072 withKASAN enabled against Windows Server 2022 and mount options'multichannel,max_channels=2,vers=3.1.1,mfsymlinks,noperm' BUG: KASAN: slab-use-after-free in smb2_query_info_compound+0x423/0x6d0 [cifs] Read of size 8 at addr ffff888014941048 by task xfs_io/27534 CPU: 0 PID: 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Call Trace: dump_stack_lvl+0x4a/0x80 print_report+0xcf/0x650 ? srso_alias_return_thunk+0x5/0x7f ? srso_alias_return_thunk+0x5/0x7f ? __phys_addr+0x46/0x90 kasan_report+0xda/0x110 ? smb2_query_info_compound+0x423/0x6d0 [cifs] ? smb2_query_info_compound+0x423/0x6d0 [cifs] smb2_query_info_compound+0x423/0x6d0 [cifs] ? __pfx_smb2_query_info_compound+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f ? __stack_depot_save+0x39/0x480 ? kasan_save_stack+0x33/0x60 ? kasan_set_track+0x25/0x30 ? ____kasan_slab_free+0x126/0x170 smb2_queryfs+0xc2/0x2c0 [cifs] ? __pfx_smb2_queryfs+0x10/0x10 [cifs] ? __pfx___lock_acquire+0x10/0x10 smb311_queryfs+0x210/0x220 [cifs] ? __pfx_smb311_queryfs+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f ? __lock_acquire+0x480/0x26c0 ? lock_release+0x1ed/0x640 ? srso_alias_return_thunk+0x5/0x7f ? do_raw_spin_unlock+0x9b/0x100 cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 ? __pfx___do_sys_fstatfs+0x10/0x10 ? srso_alias_return_thunk+0x5/0x7f ? lockdep_hardirqs_on_prepare+0x136/0x200 ? srso_alias_return_thunk+0x5/0x7f do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x8f/0xa0 open_cached_dir+0x71b/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs] smb2_queryfs+0xc2/0x2c0 [cifs] smb311_queryfs+0x210/0x220 [cifs] cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 ____kasan_slab_free+0x126/0x170 slab_free_freelist_hook+0xd0/0x1e0 __kmem_cache_free+0x9d/0x1b0 open_cached_dir+0xff5/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs] smb2_queryfs+0xc2/0x2c0 [cifs]This is a race between open_cached_dir() and cached_dir_lease_break()where the cache entry for the open directory handle receives a leasebreak while creating it. And before returning from open_cached_dir(),we put the last reference of the new @cfid because of!@cfid->has_lease.Besides the UAF, while running xfstests a lot of missed lease breakshave been noticed in tests that run several concurrent statfs(2) callson those cached fids CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108 CIFS: VFS: Dump pending requests: CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 000000005aa7316e len 108 ...To fix both, in open_cached_dir() ensure that @cfid->has_lease is setright before sending out compounded request so that any potentiallease break will be get processed by demultiplex thread while we'restill caching @cfid. And, if open failed for some reason, re-check@cfid->has_lease to decide whether or not put lease reference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52796 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: add ipvlan_route_v6_outbound() helperInspired by syzbot reports using a stack of multiple ipvlan devices.Reduce stack size needed in ipvlan_process_v6_outbound() by movingthe flowi6 struct used for the route lookup in an non inlinedhelper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,immediately reclaimed.Also make sure ipvlan_process_v4_outbound() is not inlined.We might also have to lower MAX_NEST_DEV, because only syzbot usessetups with more than four stacked devices.BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)stack guard page: 0000 [#1] SMP KASANCPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89RSP: 0018:ffffc9000e804000 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080cR13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:<#DF>[] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31[] instrument_atomic_read include/linux/instrumented.h:72 [inline][] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline][] cpumask_test_cpu include/linux/cpumask.h:506 [inline][] cpu_online include/linux/cpumask.h:1092 [inline][] trace_lock_acquire include/trace/events/lock.h:24 [inline][] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632[] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306[] rcu_read_lock include/linux/rcupdate.h:747 [inline][] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221[] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606[] pol_lookup_func include/net/ip6_fib.h:584 [inline][] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116[] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638[] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651[] ip6_route_output include/net/ip6_route.h:100 [inline][] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline][] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline][] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline][] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677[] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229[] netdev_start_xmit include/linux/netdevice.h:4966 [inline][] xmit_one net/core/dev.c:3644 [inline][] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660[] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324[] dev_queue_xmit include/linux/netdevice.h:3067 [inline][] neigh_hh_output include/net/neighbour.h:529 [inline][

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52808 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfsIf init debugfs failed during device registration due to memory allocationfailure, debugfs_remove_recursive() is called, after which debugfs_dir isnot set to NULL. debugfs_remove_recursive() will be called again duringdevice removal. As a result, illegal pointer is accessed.[ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs!...[ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0[ 1669.872669] pc : down_write+0x24/0x70[ 1669.876315] lr : down_write+0x1c/0x70[ 1669.879961] sp : ffff000036f53a30[ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8[ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000[ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270[ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8[ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310[ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10[ 1669.914982] x17: 0000000000000000 x16: 0000000000000000[ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870[ 1669.925555] x13: 0000000000000040 x12: 0000000000000228[ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0[ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10[ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff[ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00[ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000[ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001[ 1669.962563] Call trace:[ 1669.965000] down_write+0x24/0x70[ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0[ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main][ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw][ 1669.984175] pci_device_remove+0x48/0xd8[ 1669.988082] device_release_driver_internal+0x1b4/0x250[ 1669.993282] device_release_driver+0x28/0x38[ 1669.997534] pci_stop_bus_device+0x84/0xb8[ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40[ 1670.007244] remove_store+0xfc/0x140[ 1670.010802] dev_attr_store+0x44/0x60[ 1670.014448] sysfs_kf_write+0x58/0x80[ 1670.018095] kernfs_fop_write+0xe8/0x1f0[ 1670.022000] __vfs_write+0x60/0x190[ 1670.025472] vfs_write+0xac/0x1c0[ 1670.028771] ksys_write+0x6c/0xd8[ 1670.032071] __arm64_sys_write+0x24/0x30[ 1670.035977] el0_svc_common+0x78/0x130[ 1670.039710] el0_svc_handler+0x38/0x78[ 1670.043442] el0_svc+0x8/0xcTo fix this, set debugfs_dir to NULL after debugfs_remove_recursive().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52813 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: pcrypt - Fix hungtask for PADATA_RESETWe found a hungtask bug in test_aead_vec_cfg as follows:INFO: task cryptomgr_test:391009 blocked for more than 120 seconds."echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.Call trace: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_vec_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasksFor padata_do_parallel, when the return err is 0 or -EBUSY, it will callwait_for_completion(&wait->completion) in test_aead_vec_cfg. In normalcase, aead_request_complete() will be called in pcrypt_aead_serial and thereturn err is 0 for padata_do_parallel. But, when pinst->flags isPADATA_RESET, the return err is -EBUSY for padata_do_parallel, and itwon't call aead_request_complete(). Therefore, test_aead_vec_cfg willhung at wait_for_completion(&wait->completion), which will causehungtask.The problem comes as following:(padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | if (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return errIn order to resolve the problem, we replace the return err -EBUSY with-EAGAIN, which means parallel_data is changing, and the caller should callit again.v3:remove retry and just change the return err.v2:introduce padata_try_do_parallel() in pcrypt_aead_encrypt andpcrypt_aead_decrypt to solve the hungtask.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52843 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:llc: verify mac len before reading mac headerLLC reads the mac header with eth_hdr without verifying that the skbhas an Ethernet header.Syzbot was able to enter llc_rcv on a tun device. Tun can insertpackets without mac len and with user configurable skb->protocol(passing a tun_pi header when not configuring IFF_NO_PI). BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline] BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline] llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218 __netif_receive_skb_one_core net/core/dev.c:5523 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637 netif_receive_skb_internal net/core/dev.c:5723 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5782 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002Add a mac_len test before all three eth_hdr(skb) calls under net/llc.There are further uses in include/net/llc_pdu.h. All these areprotected by a test skb->protocol == ETH_P_802_2. Which does notprotect against this tun scenario.But the mac_len test added in this patch in llc_fixup_skb willindirectly protect those too. That is called from llc_rcv before anyother LLC code.It is tempting to just add a blanket mac_len check in llc_rcv, butnot sure whether that could break valid LLC paths that do not assumean Ethernet header. 802.2 LLC may be used on top of non-802.3protocols in principle. The below referenced commit shows that usedto, on top of Token Ring.At least one of the three eth_hdr uses goes back to before the startof git history. But the one that syzbot exercises is introduced inthis commit. That commit is old enough (2008), that effectively allstable kernels should receive this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52845 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Change nla_policy for bearer-related names to NLA_NUL_STRINGsyzbot reported the following uninit-value access issue [1]:=====================================================BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756 strlen lib/string.c:418 [inline] strstr+0xb8/0x2f0 lib/string.c:756 tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595 genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline] genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066 netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline] netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdTIPC bearer-related names including link names must be null-terminatedstrings. If a link name which is not null-terminated is passed throughnetlink, strstr() and similar functions can cause buffer overrun. Thiscauses the above issue.This patch changes the nla_policy for bearer-related names from NLA_STRINGto NLA_NUL_STRING. This resolves the issue by ensuring that onlynull-terminated strings are accepted as bearer-related names.syzbot reported similar uninit-value issue related to bearer names [2]. Theroot cause of this issue is that a non-null-terminated bearer name waspassed. This patch also resolved this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (axi-fan-control) Fix possible NULL pointer dereferenceaxi_fan_control_irq_handler(), dependent on the privateaxi_fan_control_data structure, might be called before the hwmondevice is registered. That will cause an "Unable to handle kernelNULL pointer dereference" error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52889 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: Fix null pointer deref when receiving skb during sock creationThe panic below is observed when receiving ICMP packets with secmark setwhile an ICMP raw socket is being created. SK_CTX(sk)->label is updatedin apparmor_socket_post_create(), but the packet is delivered to thesocket before that, causing the null pointer dereference.Drop the packet if label context is not set. BUG: kernel NULL pointer dereference, address: 000000000000004c #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: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020 RIP: 0010:aa_label_next_confined+0xb/0x40 Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2 RSP: 0018:ffffa92940003b08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002 R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400 R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000 FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0 PKRU: 55555554 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? exc_page_fault+0x7f/0x180 ? asm_exc_page_fault+0x26/0x30 ? aa_label_next_confined+0xb/0x40 apparmor_secmark_check+0xec/0x330 security_sock_rcv_skb+0x35/0x50 sk_filter_trim_cap+0x47/0x250 sock_queue_rcv_skb_reason+0x20/0x60 raw_rcv+0x13c/0x210 raw_local_deliver+0x1f3/0x250 ip_protocol_deliver_rcu+0x4f/0x2f0 ip_local_deliver_finish+0x76/0xa0 __netif_receive_skb_one_core+0x89/0xa0 netif_receive_skb+0x119/0x170 ? __netdev_alloc_skb+0x3d/0x140 vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a] vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a] __napi_poll+0x28/0x1b0 net_rx_action+0x2a4/0x380 __do_softirq+0xd1/0x2c8 __irq_exit_rcu+0xbb/0xf0 common_interrupt+0x86/0xa0 asm_common_interrupt+0x26/0x40 RIP: 0010:apparmor_socket_post_create+0xb/0x200 Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 <55> 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48 RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286 RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003 R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748 ? __pfx_apparmor_socket_post_create+0x10/0x10 security_socket_post_create+0x4b/0x80 __sock_create+0x176/0x1f0 __sys_socket+0x89/0x100 __x64_sys_socket+0x17/0x20 do_syscall_64+0x5d/0x90 ? do_syscall_64+0x6c/0x90 ? do_syscall_64+0x6c/0x90 ? do_syscall_64+0x6c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Add exception protection processing for vd in axi_chan_handle_err functionSince there is no protection for vd, a kernel panic will betriggered here in exceptional cases.You can refer to the processing of axi_chan_block_xfer_complete functionThe triggered kernel panic is as follows:[ 67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060[ 67.848447] Mem abort info:[ 67.848449] ESR = 0x96000004[ 67.848451] EC = 0x25: DABT (current EL), IL = 32 bits[ 67.848454] SET = 0, FnV = 0[ 67.848456] EA = 0, S1PTW = 0[ 67.848458] Data abort info:[ 67.848460] ISV = 0, ISS = 0x00000004[ 67.848462] CM = 0, WnR = 0[ 67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000[ 67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000[ 67.848472] Internal error: Oops: 96000004 [#1] SMP[ 67.848475] Modules linked in: dmatest[ 67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11[ 67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--)[ 67.848487] pc : axi_chan_handle_err+0xc4/0x230[ 67.848491] lr : axi_chan_handle_err+0x30/0x230[ 67.848493] sp : ffff0803fe55ae50[ 67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200[ 67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080[ 67.848504] x25: ffff800010d33880 x24: ffff80001139d850[ 67.848508] x23: ffff0800c097c168 x22: 0000000000000000[ 67.848512] x21: 0000000000000080 x20: 0000000000002000[ 67.848517] x19: ffff0800c097c080 x18: 0000000000000000[ 67.848521] x17: 0000000000000000 x16: 0000000000000000[ 67.848525] x15: 0000000000000000 x14: 0000000000000000[ 67.848529] x13: 0000000000000000 x12: 0000000000000040[ 67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a[ 67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270[ 67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0[ 67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480[ 67.848550] x3 : dead000000000100 x2 : dead000000000122[ 67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168[ 67.848559] Call trace:[ 67.848562] axi_chan_handle_err+0xc4/0x230[ 67.848566] dw_axi_dma_interrupt+0xf4/0x590[ 67.848569] __handle_irq_event_percpu+0x60/0x220[ 67.848573] handle_irq_event+0x64/0x120[ 67.848576] handle_fasteoi_irq+0xc4/0x220[ 67.848580] __handle_domain_irq+0x80/0xe0[ 67.848583] gic_handle_irq+0xc0/0x138[ 67.848585] el1_irq+0xc8/0x180[ 67.848588] arch_cpu_idle+0x14/0x2c[ 67.848591] default_idle_call+0x40/0x16c[ 67.848594] do_idle+0x1f0/0x250[ 67.848597] cpu_startup_entry+0x2c/0x60[ 67.848600] rest_init+0xc0/0xcc[ 67.848603] arch_call_rest_init+0x14/0x1c[ 67.848606] start_kernel+0x4cc/0x500[ 67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1)[ 67.848613] ---[ end trace 585a97036f88203a ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52906 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_mpls: Fix warning during failed attribute validationThe 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has avalidation type of 'NLA_VALIDATE_FUNCTION'. This is an invalidcombination according to the comment above 'struct nla_policy':"Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN: NLA_BINARY Validation function called for the attribute. All other Unused - but note that it's a union"This can trigger the warning [1] in nla_get_range_unsigned() whenvalidation of the attribute fails. Despite being of 'NLA_U32' type, theassociated 'min'/'max' fields in the policy are negative as they arealiased by the 'validate' field.Fix by changing the attribute type to 'NLA_BINARY' which is consistentwith the above comment and all other users of NLA_POLICY_VALIDATE_FN().As a result, move the length validation to the validation function.No regressions in MPLS tests: # ./tdc.py -f tc-tests/actions/mpls.json [...] # echo $? 0[1]WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117Modules linked in:CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSrel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117[...]Call Trace: __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310 netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411 netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline] netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506 netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546 rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0x38f/0x500 net/socket.c:2482 ___sys_sendmsg net/socket.c:2536 [inline] __sys_sendmsg+0x197/0x230 net/socket.c:2565 __do_sys_sendmsg net/socket.c:2574 [inline] __se_sys_sendmsg net/socket.c:2572 [inline] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52915 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xferIn af9035_i2c_master_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach af9035_i2c_master_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52916 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: aspeed: Fix memory overwrite if timing is 1600x900When capturing 1600x900, system could crash when system memory usage istight.The way to reproduce this issue:1. Use 1600x900 to display on host2. Mount ISO through 'Virtual media' on OpenBMC's web3. Run script as below on host to do sha continuously #!/bin/bash while [ [1] ]; do find /media -type f -printf '"%h/%f"\n' | xargs sha256sum done4. Open KVM on OpenBMC's webThe size of macro block captured is 8x8. Therefore, we should make surethe height of src-buf is 8 aligned to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52918 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: pci: cx23885: check cx23885_vdev_init() returncx23885_vdev_init() can return a NULL pointer, but that pointeris used in the next line without a check.Add a NULL pointer check and go to the error unwind if it is NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52936 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kernel/irq/irqdomain.c: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52978 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:riscv: kprobe: Fixup kernel panic when probing an illegal positionThe kernel would panic when probed for an illegal position. eg:(CONFIG_RISCV_ISA_C=n)echo 'p:hello kernel_clone+0x16 a0=%a0' >> kprobe_eventsecho 1 > events/kprobes/hello/enablecat traceKernel panic - not syncing: stack-protector: Kernel stackis corrupted in: __do_sys_newfstatat+0xb8/0xb8CPU: 0 PID: 111 Comm: sh Not tainted6.2.0-rc1-00027-g2d398fe49a4d #490Hardware name: riscv-virtio,qemu (DT)Call Trace:[] dump_backtrace+0x38/0x48[] show_stack+0x50/0x68[] dump_stack_lvl+0x60/0x84[] dump_stack+0x20/0x30[] panic+0x160/0x374[] generic_handle_arch_irq+0x0/0xa8[] sys_newstat+0x0/0x30[] sys_clone+0x20/0x30[] ret_from_syscall+0x0/0x4---[ end Kernel panic - not syncing: stack-protector:Kernel stack is corrupted in: __do_sys_newfstatat+0xb8/0xb8 ]---That is because the kprobe's ebreak instruction broke the kernel'soriginal code. The user should guarantee the correction of the probeposition, but it couldn't make the kernel panic.This patch adds arch_check_kprobe in arch_prepare_kprobe to prevent anillegal position (Such as the middle of an instruction).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52981 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: Fix request ref counting during error capture & debugfs dumpWhen GuC support was added to error capture, the reference countingaround the request object was broken. Fix it up.The context based search manages the spinlocking around the searchinternally. So it needs to grab the reference count internally aswell. The execlist only request based search relies on externallocking, so it needs an external reference count but within thespinlock not outside it.The only other caller of the context based search is the code fordumping engine state to debugfs. That code wasn't previously gettingan explicit reference at all as it does everything while holding theexeclist specific spinlock. So, that needs updaing as well as thatspinlock doesn't help when using GuC submission. Rather than trying toconditionally get/put depending on submission model, just change it toalways do the get/put.v2: Explicitly document adding an extra blank line in some dense code(Andy Shevchenko). Fix multiple potential null pointer derefs in caseof no request found (some spotted by Tvrtko, but there was more!).Also fix a leaked request in case of !started and another in__guc_reset_context now that intel_context_find_active_request isactually reference counting the returned request.v3: Add a _get suffix to intel_context_find_active_request now that itgrabs a reference (Daniele).v4: Split the intel_guc_find_hung_context change to a separate patchand rename intel_context_find_active_request_get tointel_context_get_active_request (Tvrtko).v5: s/locking/reference counting/ in commit message (Tvrtko)(cherry picked from commit 3700e353781e27f1bc7222f51f2cc36cbeb9b4ec)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52986 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listenerA listening socket linked to a sockmap has its sk_prot overridden. Itpoints to one of the struct proto variants in tcp_bpf_prots. The variantdepends on the socket's family and which sockmap programs are attached.A child socket cloned from a TCP listener initially inherits their sk_prot.But before cloning is finished, we restore the child's proto to thelistener's original non-tcp_bpf_prots one. This happens intcp_create_openreq_child -> tcp_bpf_clone.Today, in tcp_bpf_clone we detect if the child's proto should be restoredby checking only for the TCP_BPF_BASE proto variant. This is notcorrect. The sk_prot of listening socket linked to a sockmap can point toto any variant in tcp_bpf_prots.If the listeners sk_prot happens to be not the TCP_BPF_BASE variant, thenthe child socket unintentionally is left if the inherited sk_prot bytcp_bpf_clone.This leads to issues like infinite recursion on close [1], because thechild state is otherwise not set up for use with tcp_bpf_prot operations.Adjust the check in tcp_bpf_clone to detect all of tcp_bpf_prots variants.Note that it wouldn't be sufficient to check the socket state whenoverriding the sk_prot in tcp_bpf_update_proto in order to always use theTCP_BPF_BASE variant for listening sockets. Since commitb8b8315e39ff ("bpf, sockmap: Remove unhash handler for BPF sockmap usage")it is possible for a socket to transition to TCP_LISTEN state while alreadylinked to a sockmap, e.g. connect() -> insert into map ->connect(AF_UNSPEC) -> listen().[1]: https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52991 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix NULL pointer in skb_segment_listCommit 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")introduced UDP listifyed GRO. The segmentation relies on frag_list beinguntouched when passing through the network stack. This assumption can bebroken sometimes, where frag_list itself gets pulled into linear area,leaving frag_list being NULL. When this happens it can triggerfollowing NULL pointer dereference, and panic the kernel. Reverse thetest condition should fix it.[19185.577801][ C1] BUG: kernel NULL pointer dereference, address:...[19185.663775][ C1] RIP: 0010:skb_segment_list+0x1cc/0x390...[19185.834644][ C1] Call Trace:[19185.841730][ C1] [19185.848563][ C1] __udp_gso_segment+0x33e/0x510[19185.857370][ C1] inet_gso_segment+0x15b/0x3e0[19185.866059][ C1] skb_mac_gso_segment+0x97/0x110[19185.874939][ C1] __skb_gso_segment+0xb2/0x160[19185.883646][ C1] udp_queue_rcv_skb+0xc3/0x1d0[19185.892319][ C1] udp_unicast_rcv_skb+0x75/0x90[19185.900979][ C1] ip_protocol_deliver_rcu+0xd2/0x200[19185.910003][ C1] ip_local_deliver_finish+0x44/0x60[19185.918757][ C1] __netif_receive_skb_one_core+0x8b/0xa0[19185.927834][ C1] process_backlog+0x88/0x130[19185.935840][ C1] __napi_poll+0x27/0x150[19185.943447][ C1] net_rx_action+0x27e/0x5f0[19185.951331][ C1] ? mlx5_cq_tasklet_cb+0x70/0x160 [mlx5_core][19185.960848][ C1] __do_softirq+0xbc/0x25d[19185.968607][ C1] irq_exit_rcu+0x83/0xb0[19185.976247][ C1] common_interrupt+0x43/0xa0[19185.984235][ C1] asm_common_interrupt+0x22/0x40...[19186.094106][ C1]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52994 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:acpi: Fix suspend with Xen PVCommit f1e525009493 ("x86/boot: Skip realmode init code when running asXen PV guest") missed one code path accessing real_mode_header, leadingto dereferencing NULL when suspending the system under Xen: [ 348.284004] PM: suspend entry (deep) [ 348.289532] Filesystems sync: 0.005 seconds [ 348.291545] Freezing user space processes ... (elapsed 0.000 seconds) done. [ 348.292457] OOM killer disabled. [ 348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 seconds) done. [ 348.396612] printk: Suspending console(s) (use no_console_suspend to debug) [ 348.749228] PM: suspend devices took 0.352 seconds [ 348.769713] ACPI: EC: interrupt blocked [ 348.816077] BUG: kernel NULL pointer dereference, address: 000000000000001c [ 348.816080] #PF: supervisor read access in kernel mode [ 348.816081] #PF: error_code(0x0000) - not-present page [ 348.816083] PGD 0 P4D 0 [ 348.816086] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 6.1.3-1.fc32.qubes.x86_64 #1 [ 348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 07/03/2022 [ 348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20Fix that by adding an optional acpi callback allowing to skip settingthe wakeup address, as in the Xen PV case this will be handled by thehypervisor anyway.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52995 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:riscv/kprobe: Fix instruction simulation of JALRSet kprobe at 'jalr 1140(ra)' of vfs_write results in the followingcrash:[ 32.092235] Unable to handle kernel access to user memory without uaccess routines at virtual address 00aaaaaad77b1170[ 32.093115] Oops [#1][ 32.093251] Modules linked in:[ 32.093626] CPU: 0 PID: 135 Comm: ftracetest Not tainted 6.2.0-rc2-00013-gb0aa5e5df0cb-dirty #16[ 32.093985] Hardware name: riscv-virtio,qemu (DT)[ 32.094280] epc : ksys_read+0x88/0xd6[ 32.094855] ra : ksys_read+0xc0/0xd6[ 32.095016] epc : ffffffff801cda80 ra : ffffffff801cdab8 sp : ff20000000d7bdc0[ 32.095227] gp : ffffffff80f14000 tp : ff60000080f9cb40 t0 : ffffffff80f13e80[ 32.095500] t1 : ffffffff8000c29c t2 : ffffffff800dbc54 s0 : ff20000000d7be60[ 32.095716] s1 : 0000000000000000 a0 : ffffffff805a64ae a1 : ffffffff80a83708[ 32.095921] a2 : ffffffff80f160a0 a3 : 0000000000000000 a4 : f229b0afdb165300[ 32.096171] a5 : f229b0afdb165300 a6 : ffffffff80eeebd0 a7 : 00000000000003ff[ 32.096411] s2 : ff6000007ff76800 s3 : fffffffffffffff7 s4 : 00aaaaaad77b1170[ 32.096638] s5 : ffffffff80f160a0 s6 : ff6000007ff76800 s7 : 0000000000000030[ 32.096865] s8 : 00ffffffc3d97be0 s9 : 0000000000000007 s10: 00aaaaaad77c9410[ 32.097092] s11: 0000000000000000 t3 : ffffffff80f13e48 t4 : ffffffff8000c29c[ 32.097317] t5 : ffffffff8000c29c t6 : ffffffff800dbc54[ 32.097505] status: 0000000200000120 badaddr: 00aaaaaad77b1170 cause: 000000000000000d[ 32.098011] [] ksys_write+0x6c/0xd6[ 32.098222] [] sys_write+0x2a/0x38[ 32.098405] [] ret_from_syscall+0x0/0x2Since the rs1 and rd might be the same one, such as 'jalr 1140(ra)',hence it requires obtaining the target address from rs1 followed byupdating rd.[Palmer: Pick Guo's cleanup]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52996 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: prevent potential spectre v1 gadget in fib_metrics_match()if (!type) continue; if (type > RTAX_MAX) return false; ... fi_val = fi->fib_metrics->metrics[type - 1];@type being used as an array index, we need to preventcpu speculation or risk leaking kernel memory content.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-52997 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: prevent potential spectre v1 gadget in ip_metrics_convert()if (!type) continue; if (type > RTAX_MAX) return -EINVAL; ... metrics[type - 1] = val;@type being used as an array index, we need to preventcpu speculation or risk leaking kernel memory content.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: Fix a memory leak with reused mmap_offsetdrm_vma_node_allow() and drm_vma_node_revoke() should be called inbalanced pairs. We call drm_vma_node_allow() once per-file everytime auser calls mmap_offset, but only call drm_vma_node_revoke once per-fileon each mmap_offset. As the mmap_offset is reused by the client, theper-file vm_count may remain non-zero and the rbtree leaked.Call drm_vma_node_allow_once() instead to prevent that memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53003 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info's pvt_infoThe memory for llcc_driv_data is allocated by the LLCC driver. But whenit is passed as the private driver info to the EDAC core, it will get freedduring the qcom_edac driver release. So when the qcom_edac driver gets probedagain, it will try to use the freed data leading to the use-after-free bug.Hence, do not pass llcc_driv_data as pvt_info but rather reference itusing the platform_data pointer in the qcom_edac driver.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53009 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Add sync after creating vram boThere will be data corruption on vram allocated by svmif the initialization is not complete and application iswritting on the memory. Adding sync to wait for theinitialization completion is to resolve this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53011 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: enable all safety features by defaultIn the original implementation of dwmac5commit 8bf993a5877e ("net: stmmac: Add support for DWMAC5 and implement Safety Features")all safety features were enabled by default.Later it seems some implementations didn't have support for all thefeatures, so incommit 5ac712dcdfef ("net: stmmac: enable platform specific safety features")the safety_feat_cfg structure was added to the callback and defined forsome platforms to selectively enable these safety features.The problem is that only certain platforms were given that softwaresupport. If the automotive safety package bit is set in the hardwarefeatures register the safety feature callback is called for the platform,and for platforms that didn't get a safety_feat_cfg defined this resultsin the following NULL pointer dereference:[ 7.933303] Call trace:[ 7.935812] dwmac5_safety_feat_config+0x20/0x170 [stmmac][ 7.941455] __stmmac_open+0x16c/0x474 [stmmac][ 7.946117] stmmac_open+0x38/0x70 [stmmac][ 7.950414] __dev_open+0x100/0x1dc[ 7.954006] __dev_change_flags+0x18c/0x204[ 7.958297] dev_change_flags+0x24/0x6c[ 7.962237] do_setlink+0x2b8/0xfa4[ 7.965827] __rtnl_newlink+0x4ec/0x840[ 7.969766] rtnl_newlink+0x50/0x80[ 7.973353] rtnetlink_rcv_msg+0x12c/0x374[ 7.977557] netlink_rcv_skb+0x5c/0x130[ 7.981500] rtnetlink_rcv+0x18/0x2c[ 7.985172] netlink_unicast+0x2e8/0x340[ 7.989197] netlink_sendmsg+0x1a8/0x420[ 7.993222] ____sys_sendmsg+0x218/0x280[ 7.997249] ___sys_sendmsg+0xac/0x100[ 8.001103] __sys_sendmsg+0x84/0xe0[ 8.004776] __arm64_sys_sendmsg+0x24/0x30[ 8.008983] invoke_syscall+0x48/0x114[ 8.012840] el0_svc_common.constprop.0+0xcc/0xec[ 8.017665] do_el0_svc+0x38/0xb0[ 8.021071] el0_svc+0x2c/0x84[ 8.024212] el0t_64_sync_handler+0xf4/0x120[ 8.028598] el0t_64_sync+0x190/0x194Go back to the original behavior, if the automotive safety packageis found to be supported in hardware enable all the features unlesssafety_feat_cfg is passed in saying this particular platform onlysupports a subset of the features.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53012 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: core: call put_device() only after device_register() failsput_device() shouldn't be called before a prior call todevice_register(). __thermal_cooling_device_register() doesn't followthat properly and needs fixing. Alsothermal_cooling_device_destroy_sysfs() is getting called unnecessarilyon few error paths.Fix all this by placing the calls at the right place.Based on initial work done by Caleb Connolly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ptdma: pt_core_execute_cmd() should use spinlockThe interrupt handler (pt_core_irq_handler()) of the ptdmadriver can be called from interrupt context. The code flowin this function can lead down to pt_core_execute_cmd() whichwill attempt to grab a mutex, which is not appropriate ininterrupt context and ultimately leads to a kernel panic.The fix here changes this mutex to a spinlock, which hasbeen verified to resolve the issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53020 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: close all race conditions in l2tp_tunnel_register()The code in l2tp_tunnel_register() is racy in several ways:1. It modifies the tunnel socket _after_ publishing it.2. It calls setup_udp_tunnel_sock() on an existing socket without locking.3. It changes sock lock class on fly, which triggers many syzbot reports.This patch amends all of them by moving socket initialization codebefore publishing and under sock lock. As suggested by Jakub, thel2tp lockdep class is not necessary as we can just switch tobh_lock_sock_nested().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53021 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_taprio: fix possible use-after-freesyzbot reported a nasty crash [1] in net_tx_action() whichmade little sense until we got a repro.This repro installs a taprio qdisc, but providing aninvalid TCA_RATE attribute.qdisc_create() has to destroy the just initializedtaprio qdisc, and taprio_destroy() is called.However, the hrtimer used by taprio had already fired,therefore advance_sched() called __netif_schedule().Then net_tx_action was trying to use a destroyed qdisc.We can not undo the __netif_schedule(), so we must waituntil one cpu serviced the qdisc before we can proceed.Many thanks to Alexander Potapenko for his help.[1]BUG: KMSAN: uninit-value in queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline]BUG: KMSAN: uninit-value in do_raw_spin_trylock include/linux/spinlock.h:191 [inline]BUG: KMSAN: uninit-value in __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline]BUG: KMSAN: uninit-value in _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138 queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline] do_raw_spin_trylock include/linux/spinlock.h:191 [inline] __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline] _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138 spin_trylock include/linux/spinlock.h:359 [inline] qdisc_run_begin include/net/sch_generic.h:187 [inline] qdisc_run+0xee/0x540 include/net/pkt_sched.h:125 net_tx_action+0x77c/0x9a0 net/core/dev.c:5086 __do_softirq+0x1cc/0x7fb kernel/softirq.c:571 run_ksoftirqd+0x2c/0x50 kernel/softirq.c:934 smpboot_thread_fn+0x554/0x9f0 kernel/smpboot.c:164 kthread+0x31b/0x430 kernel/kthread.c:376 ret_from_fork+0x1f/0x30Uninit was created at: slab_post_alloc_hook mm/slab.h:732 [inline] slab_alloc_node mm/slub.c:3258 [inline] __kmalloc_node_track_caller+0x814/0x1250 mm/slub.c:4970 kmalloc_reserve net/core/skbuff.c:358 [inline] __alloc_skb+0x346/0xcf0 net/core/skbuff.c:430 alloc_skb include/linux/skbuff.h:1257 [inline] nlmsg_new include/net/netlink.h:953 [inline] netlink_ack+0x5f3/0x12b0 net/netlink/af_netlink.c:2436 netlink_rcv_skb+0x55d/0x6c0 net/netlink/af_netlink.c:2507 rtnetlink_rcv+0x30/0x40 net/core/rtnetlink.c:6108 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xabc/0xe90 net/socket.c:2482 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2536 __sys_sendmsg net/socket.c:2565 [inline] __do_sys_sendmsg net/socket.c:2574 [inline] __se_sys_sendmsg net/socket.c:2572 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2572 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdCPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 6.0.0-rc2-syzkaller-47461-gac3859c02d7f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53022 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()This lockdep splat says it better than I could:================================WARNING: inconsistent lock state6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted--------------------------------inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0{IN-SOFTIRQ-W} state was registered at: _raw_spin_lock+0x5c/0xc0 sch_direct_xmit+0x148/0x37c __dev_queue_xmit+0x528/0x111c ip6_finish_output2+0x5ec/0xb7c ip6_finish_output+0x240/0x3f0 ip6_output+0x78/0x360 ndisc_send_skb+0x33c/0x85c ndisc_send_rs+0x54/0x12c addrconf_rs_timer+0x154/0x260 call_timer_fn+0xb8/0x3a0 __run_timers.part.0+0x214/0x26c run_timer_softirq+0x3c/0x74 __do_softirq+0x14c/0x5d8 ____do_softirq+0x10/0x20 call_on_irq_stack+0x2c/0x5c do_softirq_own_stack+0x1c/0x30 __irq_exit_rcu+0x168/0x1a0 irq_exit_rcu+0x10/0x40 el1_interrupt+0x38/0x64irq event stamp: 7825hardirqs last enabled at (7825): [] exit_to_kernel_mode+0x34/0x130hardirqs last disabled at (7823): [] __do_softirq+0x550/0x5d8softirqs last enabled at (7824): [] __do_softirq+0x46c/0x5d8softirqs last disabled at (7811): [] ____do_softirq+0x10/0x20other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(_xmit_ETHER#2); lock(_xmit_ETHER#2); *** DEADLOCK ***3 locks held by kworker/1:3/179: #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #1: ffff80000a0bbdc8 ((work_completion)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34Workqueue: events enetc_tx_onestep_tstampCall trace: print_usage_bug.part.0+0x208/0x22c mark_lock+0x7f0/0x8b0 __lock_acquire+0x7c4/0x1ce0 lock_acquire.part.0+0xe0/0x220 lock_acquire+0x68/0x84 _raw_spin_lock+0x5c/0xc0 netif_freeze_queues+0x5c/0xc0 netif_tx_lock+0x24/0x34 enetc_tx_onestep_tstamp+0x20/0x100 process_one_work+0x28c/0x6c0 worker_thread+0x74/0x450 kthread+0x118/0x11cbut I'll say it anyway: the enetc_tx_onestep_tstamp() work item runs inprocess context, therefore with softirqs enabled (i.o.w., it can beinterrupted by a softirq). If we hold the netif_tx_lock() when there isan interrupt, and the NET_TX softirq then gets scheduled, this will takethe netif_tx_lock() a second time and deadlock the kernel.To solve this, use netif_tx_lock_bh(), which blocks softirqs fromrunning.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53031 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/imc-pmu: Fix use of mutex in IRQs disabled sectionCurrent imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEPand CONFIG_PROVE_LOCKING enabled, while running a thread_imc event.Command to trigger the warning: # perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5 Performance counter stats for 'sleep 5': 0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ 5.002117947 seconds time elapsed 0.000131000 seconds user 0.001063000 seconds sysBelow is snippet of the warning in dmesg: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec preempt_count: 2, expected: 0 4 locks held by perf-exec/2869: #0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90 #1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0 #2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510 #3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510 irq event stamp: 4806 hardirqs last enabled at (4805): [] _raw_spin_unlock_irqrestore+0x94/0xd0 hardirqs last disabled at (4806): [] perf_event_exec+0x394/0x510 softirqs last enabled at (0): [] copy_process+0xc34/0x1ff0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 #61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV Call Trace: dump_stack_lvl+0x98/0xe0 (unreliable) __might_resched+0x2f8/0x310 __mutex_lock+0x6c/0x13f0 thread_imc_event_add+0xf4/0x1b0 event_sched_in+0xe0/0x210 merge_sched_in+0x1f0/0x600 visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0 ctx_flexible_sched_in+0xcc/0x140 ctx_sched_in+0x20c/0x2a0 ctx_resched+0x104/0x1c0 perf_event_exec+0x340/0x510 begin_new_exec+0x730/0xef0 load_elf_binary+0x3f8/0x1e10 ... do not call blocking ops when !TASK_RUNNING; state=2001 set at [<00000000fd63e7cf>] do_nanosleep+0x60/0x1a0 WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0 CPU: 36 PID: 2869 Comm: sleep Tainted: G W 6.2.0-rc2-00011-g1247637727f2 #61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV NIP: c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670 REGS: c00000004d2134e0 TRAP: 0700 Tainted: G W (6.2.0-rc2-00011-g1247637727f2) MSR: 9000000000021033 CR: 48002824 XER: 00000000 CFAR: c00000000013fb64 IRQMASK: 1The above warning triggered because the current imc-pmu code uses mutexlock in interrupt disabled sections. The function mutex_lock()internally calls __might_resched(), which will check if IRQs aredisabled and in case IRQs are disabled, it will trigger the warning.Fix the issue by changing the mutex lock to spinlock.[mpe: Fix comments, trim oops in change log, add reported-by tags]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53032 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function.When first_ip is 0, last_ip is 0xFFFFFFFF, and netmask is 31, the value ofan arithmetic expression 2 << (netmask - mask_bits - 1) is subjectto overflow due to a failure casting operands to a larger data typebefore performing the arithmetic.Note that it's harmless since the value will be checked at the next step.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53047 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tee: amdtee: fix race condition in amdtee_open_sessionThere is a potential race condition in amdtee_open_session that maylead to use-after-free. For instance, in amdtee_open_session() aftersess->sess_mask is set, and before setting: sess->session_info[i] = session_info;if amdtee_close_session() closes this same session, then 'sess' datastructure will be released, causing kernel panic when 'sess' isaccessed within amdtee_open_session().The solution is to set the bit sess->sess_mask as the last step inamdtee_open_session().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53053 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erspan: do not use skb_mac_header() in ndo_start_xmit()Drivers should not assume skb_mac_header(skb) == skb->data in theirndo_start_xmit().Use skb_network_offset() and skb_transport_offset() whichbetter describe what is needed in erspan_fb_xmit() andip6erspan_tunnel_xmit()syzbot reported:WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline]WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962Modules linked in:CPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023RIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline]RIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962Code: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 <0f> 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00RSP: 0018:ffffc90003b2f830 EFLAGS: 00010293RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000RDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003RBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffffR10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00R13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff888023408000FS: 0000555556a61300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055e5b11eb6e8 CR3: 0000000027c1b000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:__netdev_start_xmit include/linux/netdevice.h:4900 [inline]netdev_start_xmit include/linux/netdevice.h:4914 [inline]__dev_direct_xmit+0x504/0x730 net/core/dev.c:4300dev_direct_xmit include/linux/netdevice.h:3088 [inline]packet_xmit+0x20a/0x390 net/packet/af_packet.c:285packet_snd net/packet/af_packet.c:3075 [inline]packet_sendmsg+0x31a0/0x5150 net/packet/af_packet.c:3107sock_sendmsg_nosec net/socket.c:724 [inline]sock_sendmsg+0xde/0x190 net/socket.c:747__sys_sendto+0x23a/0x340 net/socket.c:2142__do_sys_sendto net/socket.c:2154 [inline]__se_sys_sendto net/socket.c:2150 [inline]__x64_sys_sendto+0xe1/0x1b0 net/socket.c:2150do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7f123aaa1039Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 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 c0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007ffc15d12058 EFLAGS: 00000246 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f123aaa1039RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003RBP: 0000000000000000 R08: 0000000020000040 R09: 0000000000000014R10: 0000000000000000 R11: 0000000000000246 R12: 00007f123aa648c0R13: 431bde82d7b634db R14: 0000000000000000 R15: 0000000000000000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-vf: Add missing free for alloc_percpuAdd the free_percpu for the allocated "vf->hw.lmt_info" in order to avoidmemory leak, same as the "pf->hw.lmt_info" in`drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c`.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53072 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: use the workqueue to destroy unaccepted socketsChristoph reported a UaF at token lookup time after havingrefactored the passive socket initialization part: BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260 Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198 CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 __token_bucket_busy+0x253/0x260 mptcp_token_new_connect+0x13d/0x490 mptcp_connect+0x4ed/0x860 __inet_stream_connect+0x80e/0xd90 tcp_sendmsg_fastopen+0x3ce/0x710 mptcp_sendmsg+0xff1/0x1a20 inet_sendmsg+0x11d/0x140 __sys_sendto+0x405/0x490 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcWe need to properly clean-up all the paired MPTCP-levelresources and be sure to release the msk last, even whenthe unaccepted subflow is destroyed by the TCP internalsvia inet_child_forget().We can re-use the existing MPTCP_WORK_CLOSE_SUBFLOW infra,explicitly checking that for the critical scenario: theclosed subflow is the MPC one, the msk is not accepted andeventually going through full cleanup.With such change, __mptcp_destroy_sock() is always calledon msk sockets, even on accepted ones. We don't need anymoreto transiently drop one sk reference at msk clone time.Please note this commit depends on the parent one: mptcp: refactor passive socket initialization

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53080 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Add missing overflow check in xdp_umem_regThe number of chunks can overflow u32. Make sure to return -EINVAL onoverflow. Also remove a redundant u32 cast assigning umem->npgs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53094 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: fsl_lpuart: fix race on RX DMA shutdownFrom time to time DMA completion can come in the middle of DMA shutdown:: :lpuart32_shutdown() lpuart_dma_shutdown() del_timer_sync() lpuart_dma_rx_complete() lpuart_copy_rx_to_tty() mod_timer() lpuart_dma_rx_free()When the timer fires a bit later, sport->dma_rx_desc is NULL:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004pc : lpuart_copy_rx_to_tty+0xcc/0x5bclr : lpuart_timer_func+0x1c/0x2cCall trace: lpuart_copy_rx_to_tty lpuart_timer_func call_timer_fn __run_timers.part.0 run_timer_softirq __do_softirq __irq_exit_rcu irq_exit handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler ...To fix this fold del_timer_sync() into lpuart_dma_rx_free() afterdmaengine_terminate_sync() to make sure timer will not be re-started inlpuart_copy_rx_to_tty() <= lpuart_dma_rx_complete().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53102 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: xsk: disable txq irq before flushing hwice_qp_dis() intends to stop a given queue pair that is a target of xskpool attach/detach. One of the steps is to disable interrupts on thesequeues. It currently is broken in a way that txq irq is turned off*after* HW flush which in turn takes no effect.ice_qp_dis():-> ice_qvec_dis_irq()--> disable rxq irq--> flush hw-> ice_vsi_stop_tx_ring()-->disable txq irqBelow splat can be triggered by following steps:- start xdpsock WITHOUT loading xdp prog- run xdp_rxq_info with XDP_TX action on this interface- start traffic- terminate xdpsock[ 256.312485] BUG: kernel NULL pointer dereference, address: 0000000000000018[ 256.319560] #PF: supervisor read access in kernel mode[ 256.324775] #PF: error_code(0x0000) - not-present page[ 256.329994] PGD 0 P4D 0[ 256.332574] Oops: 0000 [#1] PREEMPT SMP NOPTI[ 256.337006] CPU: 3 PID: 32 Comm: ksoftirqd/3 Tainted: G OE 6.2.0-rc5+ #51[ 256.345218] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[ 256.355807] RIP: 0010:ice_clean_rx_irq_zc+0x9c/0x7d0 [ice][ 256.361423] Code: b7 8f 8a 00 00 00 66 39 ca 0f 84 f1 04 00 00 49 8b 47 40 4c 8b 24 d0 41 0f b7 45 04 66 25 ff 3f 66 89 04 24 0f 84 85 02 00 00 <49> 8b 44 24 18 0f b7 14 24 48 05 00 01 00 00 49 89 04 24 49 89 44[ 256.380463] RSP: 0018:ffffc900088bfd20 EFLAGS: 00010206[ 256.385765] RAX: 000000000000003c RBX: 0000000000000035 RCX: 000000000000067f[ 256.393012] RDX: 0000000000000775 RSI: 0000000000000000 RDI: ffff8881deb3ac80[ 256.400256] RBP: 000000000000003c R08: ffff889847982710 R09: 0000000000010000[ 256.407500] R10: ffffffff82c060c0 R11: 0000000000000004 R12: 0000000000000000[ 256.414746] R13: ffff88811165eea0 R14: ffffc9000d255000 R15: ffff888119b37600[ 256.421990] FS: 0000000000000000(0000) GS:ffff8897e0cc0000(0000) knlGS:0000000000000000[ 256.430207] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 256.436036] CR2: 0000000000000018 CR3: 0000000005c0a006 CR4: 00000000007706e0[ 256.443283] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 256.450527] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 256.457770] PKRU: 55555554[ 256.460529] Call Trace:[ 256.463015] [ 256.465157] ? ice_xmit_zc+0x6e/0x150 [ice][ 256.469437] ice_napi_poll+0x46d/0x680 [ice][ 256.473815] ? _raw_spin_unlock_irqrestore+0x1b/0x40[ 256.478863] __napi_poll+0x29/0x160[ 256.482409] net_rx_action+0x136/0x260[ 256.486222] __do_softirq+0xe8/0x2e5[ 256.489853] ? smpboot_thread_fn+0x2c/0x270[ 256.494108] run_ksoftirqd+0x2a/0x50[ 256.497747] smpboot_thread_fn+0x1c1/0x270[ 256.501907] ? __pfx_smpboot_thread_fn+0x10/0x10[ 256.506594] kthread+0xea/0x120[ 256.509785] ? __pfx_kthread+0x10/0x10[ 256.513597] ret_from_fork+0x29/0x50[ 256.517238] In fact, irqs were not disabled and napi managed to be scheduled and runwhile xsk_pool pointer was still valid, but SW ring of xdp_buff pointerswas already freed.To fix this, call ice_qvec_dis_irq() after ice_vsi_stop_tx_ring(). Alsowhile at it, remove redundant ice_clean_rx_ring() call - this is handledin ice_qp_clean_rings().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53103 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave failssyzbot reported a warning[1] where the bond device itself is a slave andwe try to enslave a non-ethernet device as the first slave which failsbut then in the error path when ether_setup() restores the bond deviceit also clears all flags. In my previous fix[2] I restored theIFF_MASTER flag, but I didn't consider the case that the bond deviceitself might also be a slave with IFF_SLAVE set, so we need to restorethat flag as well. Use the bond_ether_setup helper which does the rightthing and restores the bond's flags properly.Steps to reproduce using a nlmon dev: $ ip l add nlmon0 type nlmon $ ip l add bond1 type bond $ ip l add bond2 type bond $ ip l set bond1 master bond2 $ ip l set dev nlmon0 master bond1 $ ip -d l sh dev bond1 22: bond1: mtu 1500 qdisc noqueue master bond2 state DOWN mode DEFAULT group default qlen 1000 (now bond1's IFF_SLAVE flag is gone and we'll hit a warning[3] if we try to delete it)[1] https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3ef[2] commit 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave failure")[3] example warning: [ 27.008664] bond1: (slave nlmon0): The slave device specified does not support setting the MAC address [ 27.008692] bond1: (slave nlmon0): Error -95 calling set_mac_address [ 32.464639] bond1 (unregistering): Released all slaves [ 32.464685] ------------[ cut here ]------------ [ 32.464686] WARNING: CPU: 1 PID: 2004 at net/core/dev.c:10829 unregister_netdevice_many+0x72a/0x780 [ 32.464694] Modules linked in: br_netfilter bridge bonding virtio_net [ 32.464699] CPU: 1 PID: 2004 Comm: ip Kdump: loaded Not tainted 5.18.0-rc3+ #47 [ 32.464703] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014 [ 32.464704] RIP: 0010:unregister_netdevice_many+0x72a/0x780 [ 32.464707] Code: 99 fd ff ff ba 90 1a 00 00 48 c7 c6 f4 02 66 96 48 c7 c7 20 4d 35 96 c6 05 fa c7 2b 02 01 e8 be 6f 4a 00 0f 0b e9 73 fd ff ff <0f> 0b e9 5f fd ff ff 80 3d e3 c7 2b 02 00 0f 85 3b fd ff ff ba 59 [ 32.464710] RSP: 0018:ffffa006422d7820 EFLAGS: 00010206 [ 32.464712] RAX: ffff8f6e077140a0 RBX: ffffa006422d7888 RCX: 0000000000000000 [ 32.464714] RDX: ffff8f6e12edbe58 RSI: 0000000000000296 RDI: ffffffff96d4a520 [ 32.464716] RBP: ffff8f6e07714000 R08: ffffffff96d63600 R09: ffffa006422d7728 [ 32.464717] R10: 0000000000000ec0 R11: ffffffff9698c988 R12: ffff8f6e12edb140 [ 32.464719] R13: dead000000000122 R14: dead000000000100 R15: ffff8f6e12edb140 [ 32.464723] FS: 00007f297c2f1740(0000) GS:ffff8f6e5d900000(0000) knlGS:0000000000000000 [ 32.464725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 32.464726] CR2: 00007f297bf1c800 CR3: 00000000115e8000 CR4: 0000000000350ee0 [ 32.464730] Call Trace: [ 32.464763] [ 32.464767] rtnl_dellink+0x13e/0x380 [ 32.464776] ? cred_has_capability.isra.0+0x68/0x100 [ 32.464780] ? __rtnl_unlock+0x33/0x60 [ 32.464783] ? bpf_lsm_capset+0x10/0x10 [ 32.464786] ? security_capable+0x36/0x50 [ 32.464790] rtnetlink_rcv_msg+0x14e/0x3b0 [ 32.464792] ? _copy_to_iter+0xb1/0x790 [ 32.464796] ? post_alloc_hook+0xa0/0x160 [ 32.464799] ? rtnl_calcit.isra.0+0x110/0x110 [ 32.464802] netlink_rcv_skb+0x50/0xf0 [ 32.464806] netlink_unicast+0x216/0x340 [ 32.464809] netlink_sendmsg+0x23f/0x480 [ 32.464812] sock_sendmsg+0x5e/0x60 [ 32.464815] ____sys_sendmsg+0x22c/0x270 [ 32.464818] ? import_iovec+0x17/0x20 [ 32.464821] ? sendmsg_copy_msghdr+0x59/0x90 [ 32.464823] ? do_set_pte+0xa0/0xe0 [ 32.464828] ___sys_sendmsg+0x81/0xc0 [ 32.464832] ? mod_objcg_state+0xc6/0x300 [ 32.464835] ? refill_obj_stock+0xa9/0x160 [ 32.464838] ? memcg_slab_free_hook+0x1a5/0x1f0 [ 32.464842] __sys_sendm---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53105 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix cleanup null-ptr deref on encap lockDuring module is unloaded while a peer tc flow is still offloaded,first the peer uplink rep profile is changed to a nic profile, and soneigh encap lock is destroyed. Next during unload, the VF reps netdevsare unregistered which causes the original non-peer tc flow to be deleted,which deletes the peer flow. The peer flow deletion detaches the encapentry and try to take the already destroyed encap lock, causing thebelow trace.Fix this by clearing peer flows during tc eswitch cleanup(mlx5e_tc_esw_cleanup()).Relevant trace:[ 4316.837128] BUG: kernel NULL pointer dereference, address: 00000000000001d8[ 4316.842239] RIP: 0010:__mutex_lock+0xb5/0xc40[ 4316.851897] Call Trace:[ 4316.852481] [ 4316.857214] mlx5e_rep_neigh_entry_release+0x93/0x790 [mlx5_core][ 4316.858258] mlx5e_rep_encap_entry_detach+0xa7/0xf0 [mlx5_core][ 4316.859134] mlx5e_encap_dealloc+0xa3/0xf0 [mlx5_core][ 4316.859867] clean_encap_dests.part.0+0x5c/0xe0 [mlx5_core][ 4316.860605] mlx5e_tc_del_fdb_flow+0x32a/0x810 [mlx5_core][ 4316.862609] __mlx5e_tc_del_fdb_peer_flow+0x1a2/0x250 [mlx5_core][ 4316.863394] mlx5e_tc_del_flow+0x(/0x630 [mlx5_core][ 4316.864090] mlx5e_flow_put+0x5f/0x100 [mlx5_core][ 4316.864771] mlx5e_delete_flower+0x4de/0xa40 [mlx5_core][ 4316.865486] tc_setup_cb_reoffload+0x20/0x80[ 4316.865905] fl_reoffload+0x47c/0x510 [cls_flower][ 4316.869181] tcf_block_playback_offloads+0x91/0x1d0[ 4316.869649] tcf_block_unbind+0xe7/0x1b0[ 4316.870049] tcf_block_offload_cmd.isra.0+0x1ee/0x270[ 4316.879266] tcf_block_offload_unbind+0x61/0xa0[ 4316.879711] __tcf_block_put+0xa4/0x310

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53109 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: tunnels: annotate lockless accesses to dev->needed_headroomIP tunnels can apparently update dev->needed_headroomin their xmit path.This patch takes care of three tunnels xmit, and also thecore LL_RESERVED_SPACE() and LL_RESERVED_SPACE_EXTRA()helpers.More changes might be needed for completeness.BUG: KCSAN: data-race in ip_tunnel_xmit / ip_tunnel_xmitread to 0xffff88815b9da0ec of 2 bytes by task 888 on cpu 1:ip_tunnel_xmit+0x1270/0x1730 net/ipv4/ip_tunnel.c:803__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430dst_output include/net/dst.h:444 [inline]ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430dst_output include/net/dst.h:444 [inline]ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430dst_output include/net/dst.h:444 [inline]ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/i---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53110 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()When performing a stress test on SMC-R by rmmod mlx5_ib driverduring the wrk/nginx test, we found that there is a probabilityof triggering a panic while terminating all link groups.This issue dues to the race between smc_smcr_terminate_all()and smc_buf_create(). smc_smcr_terminate_allsmc_buf_create/* init */conn->sndbuf_desc = NULL;... __smc_lgr_terminate smc_conn_kill smc_close_abort smc_cdc_get_slot_and_msg_send __softirqentry_text_start smc_wr_tx_process_cqe smc_cdc_tx_handler READ(conn->sndbuf_desc->len); /* panic dues to NULL sndbuf_desc */conn->sndbuf_desc = xxx;This patch tries to fix the issue by always to check the sndbuf_descbefore send any cdc msg, to make sure that no null pointer isseen during cqe processing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53121 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: tcp_make_synack() can be called from process contexttcp_rtx_synack() now could be called in process context as explained in0a375c822497 ("tcp: tcp_rtx_synack() can be called from processcontext").tcp_rtx_synack() might call tcp_make_synack(), which will touch per-CPUvariables with preemption enabled. This causes the following BUG: BUG: using __this_cpu_add() in preemptible [00000000] code: ThriftIO1/5464 caller is tcp_make_synack+0x841/0xac0 Call Trace: dump_stack_lvl+0x10d/0x1a0 check_preemption_disabled+0x104/0x110 tcp_make_synack+0x841/0xac0 tcp_v6_send_synack+0x5c/0x450 tcp_rtx_synack+0xeb/0x1f0 inet_rtx_syn_ack+0x34/0x60 tcp_check_req+0x3af/0x9e0 tcp_rcv_state_process+0x59b/0x2030 tcp_v6_do_rcv+0x5f5/0x700 release_sock+0x3a/0xf0 tcp_sendmsg+0x33/0x40 ____sys_sendmsg+0x2f2/0x490 __sys_sendmsg+0x184/0x230 do_syscall_64+0x3d/0x90Avoid calling __TCP_INC_STATS() with will touch per-cpu variables. UseTCP_INC_STATS() which is safe to be called from context switch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53133 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser()When the buffer length of the recvmsg system call is 0, we got theflollowing soft lockup problem:watchdog: BUG: soft lockup - CPU#3 stuck for 27s! [a.out:6149]CPU: 3 PID: 6149 Comm: a.out Kdump: loaded Not tainted 6.2.0+ #30Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014RIP: 0010:remove_wait_queue+0xb/0xc0Code: 5e 41 5f c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 57 <41> 56 41 55 41 54 55 48 89 fd 53 48 89 f3 4c 8d 6b 18 4c 8d 73 20RSP: 0018:ffff88811b5978b8 EFLAGS: 00000246RAX: 0000000000000000 RBX: ffff88811a7d3780 RCX: ffffffffb7a4d768RDX: dffffc0000000000 RSI: ffff88811b597908 RDI: ffff888115408040RBP: 1ffff110236b2f1b R08: 0000000000000000 R09: ffff88811a7d37e7R10: ffffed10234fa6fc R11: 0000000000000001 R12: ffff88811179b800R13: 0000000000000001 R14: ffff88811a7d38a8 R15: ffff88811a7d37e0FS: 00007f6fb5398740(0000) GS:ffff888237180000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000000 CR3: 000000010b6ba002 CR4: 0000000000370ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_msg_wait_data+0x279/0x2f0 tcp_bpf_recvmsg_parser+0x3c6/0x490 inet_recvmsg+0x280/0x290 sock_recvmsg+0xfc/0x120 ____sys_recvmsg+0x160/0x3d0 ___sys_recvmsg+0xf0/0x180 __sys_recvmsg+0xea/0x1a0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcThe logic in tcp_bpf_recvmsg_parser is as follows:msg_bytes_ready: copied = sk_msg_recvmsg(sk, psock, msg, len, flags); if (!copied) { wait data; goto msg_bytes_ready; }In this case, "copied" always is 0, the infinite loop occurs.According to the Linux system call man page, 0 should be returned in thiscase. Therefore, in tcp_bpf_recvmsg_parser(), if the length is 0, directlyreturn. Also modify several other functions with the same problem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53135 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:riscv: Use READ_ONCE_NOCHECK in imprecise unwinding stack modeWhen CONFIG_FRAME_POINTER is unset, the stack unwinding functionwalk_stackframe randomly reads the stack and then, when KASAN is enabled,it can lead to the following backtrace:[ 0.000000] ==================================================================[ 0.000000] BUG: KASAN: stack-out-of-bounds in walk_stackframe+0xa6/0x11a[ 0.000000] Read of size 8 at addr ffffffff81807c40 by task swapper/0[ 0.000000][ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.2.0-12919-g24203e6db61f #43[ 0.000000] Hardware name: riscv-virtio,qemu (DT)[ 0.000000] Call Trace:[ 0.000000] [] walk_stackframe+0x0/0x11a[ 0.000000] [] init_param_lock+0x26/0x2a[ 0.000000] [] walk_stackframe+0xa2/0x11a[ 0.000000] [] dump_stack_lvl+0x22/0x36[ 0.000000] [] print_report+0x198/0x4a8[ 0.000000] [] init_param_lock+0x26/0x2a[ 0.000000] [] walk_stackframe+0xa2/0x11a[ 0.000000] [] kasan_report+0x9a/0xc8[ 0.000000] [] walk_stackframe+0xa2/0x11a[ 0.000000] [] walk_stackframe+0xa2/0x11a[ 0.000000] [] desc_make_final+0x80/0x84[ 0.000000] [] stack_trace_save+0x88/0xa6[ 0.000000] [] filter_irq_stacks+0x72/0x76[ 0.000000] [] devkmsg_read+0x32a/0x32e[ 0.000000] [] kasan_save_stack+0x28/0x52[ 0.000000] [] desc_make_final+0x7c/0x84[ 0.000000] [] stack_trace_save+0x84/0xa6[ 0.000000] [] kasan_set_track+0x12/0x20[ 0.000000] [] __kasan_slab_alloc+0x58/0x5e[ 0.000000] [] __kmem_cache_create+0x21e/0x39a[ 0.000000] [] create_boot_cache+0x70/0x9c[ 0.000000] [] kmem_cache_init+0x6c/0x11e[ 0.000000] [] mm_init+0xd8/0xfe[ 0.000000] [] start_kernel+0x190/0x3ca[ 0.000000][ 0.000000] The buggy address belongs to stack of task swapper/0[ 0.000000] and is located at offset 0 in frame:[ 0.000000] stack_trace_save+0x0/0xa6[ 0.000000][ 0.000000] This frame has 1 object:[ 0.000000] [32, 56) 'c'[ 0.000000][ 0.000000] The buggy address belongs to the physical page:[ 0.000000] page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x81a07[ 0.000000] flags: 0x1000(reserved|zone=0)[ 0.000000] raw: 0000000000001000 ff600003f1e3d150 ff600003f1e3d150 0000000000000000[ 0.000000] raw: 0000000000000000 0000000000000000 00000001ffffffff[ 0.000000] page dumped because: kasan: bad access detected[ 0.000000][ 0.000000] Memory state around the buggy address:[ 0.000000] ffffffff81807b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 0.000000] ffffffff81807b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 0.000000] >ffffffff81807c00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 f3[ 0.000000] ^[ 0.000000] ffffffff81807c80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00[ 0.000000] ffffffff81807d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 0.000000] ==================================================================Fix that by using READ_ONCE_NOCHECK when reading the stack in imprecisemode.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53138 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: caif: Fix use-after-free in cfusbl_device_notify()syzbot reported use-after-free in cfusbl_device_notify() [1]. Thiscauses a stack trace like below:BUG: KASAN: use-after-free in cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138Read of size 8 at addr ffff88807ac4e6f0 by task kworker/u4:6/1214CPU: 0 PID: 1214 Comm: kworker/u4:6 Not tainted 5.19.0-rc3-syzkaller-00146-g92f20ff72066 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xeb/0x467 mm/kasan/report.c:313 print_report mm/kasan/report.c:429 [inline] kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491 cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138 notifier_call_chain+0xb5/0x200 kernel/notifier.c:87 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10227 [inline] netdev_run_todo+0xbc0/0x10f0 net/core/dev.c:10341 default_device_exit_batch+0x44e/0x590 net/core/dev.c:11334 ops_exit_list+0x125/0x170 net/core/net_namespace.c:167 cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 When unregistering a net device, unregister_netdevice_many_notify()sets the device's reg_state to NETREG_UNREGISTERING, calls notifierswith NETDEV_UNREGISTER, and adds the device to the todo list.Later on, devices in the todo list are processed by netdev_run_todo().netdev_run_todo() waits devices' reference count become 1 whilerebdoadcasting NETDEV_UNREGISTER notification.When cfusbl_device_notify() is called with NETDEV_UNREGISTER multipletimes, the parent device might be freed. This could cause UAF.Processing NETDEV_UNREGISTER multiple times also causes inbalance ofreference count for the module.This patch fixes the issue by accepting only first NETDEV_UNREGISTERnotification.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53141 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()ila_xlat_nl_cmd_get_mapping() generates an empty skb,triggerring a recent sanity check [1].Instead, return an error code, so that user spacecan get it.[1]skb_assert_lenWARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [inline]WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156Modules linked in:CPU: 0 PID: 5923 Comm: syz-executor269 Not tainted 6.2.0-syzkaller-18300-g2ebd1fbb946d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : skb_assert_len include/linux/skbuff.h:2527 [inline]pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156lr : skb_assert_len include/linux/skbuff.h:2527 [inline]lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156sp : ffff80001e0d6c40x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0x17: 0000000000000000 x16: ffff80001235d16c x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001x11: ff80800008353a30 x10: 0000000000000000 x9 : 21567eaf25bfb600x8 : 21567eaf25bfb600 x7 : 0000000000000001 x6 : 0000000000000001x5 : ffff80001e0d6558 x4 : ffff800015c74760 x3 : ffff800008596744x2 : 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000eCall trace:skb_assert_len include/linux/skbuff.h:2527 [inline]__dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156dev_queue_xmit include/linux/netdevice.h:3033 [inline]__netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [inline]__netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338__netlink_sendskb net/netlink/af_netlink.c:1283 [inline]netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380nlmsg_unicast include/net/netlink.h:1099 [inline]genlmsg_unicast include/net/genetlink.h:433 [inline]genlmsg_reply include/net/genetlink.h:443 [inline]ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942sock_sendmsg_nosec net/socket.c:714 [inline]sock_sendmsg net/socket.c:734 [inline]____sys_sendmsg+0x558/0x844 net/socket.c:2479___sys_sendmsg net/socket.c:2533 [inline]__sys_sendmsg+0x26c/0x33c net/socket.c:2562__do_sys_sendmsg net/socket.c:2571 [inline]__se_sys_sendmsg net/socket.c:2569 [inline]__arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591irq event stamp: 136484hardirqs last enabled at (136483): [] __up_console_sem+0x60/0xb4 kernel/printk/printk.c:345hardirqs last disabled at (136484): [] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:405softirqs last enabled at (136418): [] softirq_ha---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53146 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: dw2102: Fix null-ptr-deref in dw2102_i2c_transfer()In dw2102_i2c_transfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach dw2102_i2c_transfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 950e252cb469("[media] dw2102: limit messages to buffer size")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53152 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix calltrace warning in amddrm_buddy_finiThe following call trace is observed when removing the amdgpu driver, whichis caused by that BOs allocated for psp are not freed until removing.[61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy][61811.450577] Call Trace:[61811.450577] [61811.450579] amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu][61811.450728] amdgpu_ttm_fini+0x207/0x290 [amdgpu][61811.450870] amdgpu_bo_fini+0x27/0xa0 [amdgpu][61811.451012] gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu][61811.451166] amdgpu_device_fini_sw+0x117/0x520 [amdgpu][61811.451306] amdgpu_driver_release_kms+0x16/0x30 [amdgpu][61811.451447] devm_drm_dev_init_release+0x4d/0x80 [drm][61811.451466] devm_action_release+0x15/0x20[61811.451469] release_nodes+0x40/0xb0[61811.451471] devres_release_all+0x9b/0xd0[61811.451473] __device_release_driver+0x1bb/0x2a0[61811.451476] driver_detach+0xf3/0x140[61811.451479] bus_remove_driver+0x6c/0xf0[61811.451481] driver_unregister+0x31/0x60[61811.451483] pci_unregister_driver+0x40/0x90[61811.451486] amdgpu_exit+0x15/0x447 [amdgpu]For smu v13_0_2, if the GPU supports xgmi, refer tocommit f5c7e7797060 ("drm/amdgpu: Adjust removal control flow for smu v13_0_2"),it will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing,which makes all devices in hive list have hw reset but no resume except thebasic ip blocks, then other ip blocks will not call .hw_fini according toip_block.status.hw.Since psp_free_shared_bufs just includes some software operations, so moveit to psp_sw_fini.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53164 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_probeof_irq_find_parent() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53183 Severity: Moderate CVSS3 score: 5.5

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

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53186 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:skbuff: Fix a race between coalescing and releasing SKBsCommit 1effe8ca4e34 ("skbuff: fix coalescing for page_pool fragmentrecycling") allowed coalescing to proceed with non page pool page and pagepool page when @from is cloned, i.e.to->pp_recycle --> falsefrom->pp_recycle --> trueskb_cloned(from) --> trueHowever, it actually requires skb_cloned(@from) to hold true untilcoalescing finishes in this situation. If the other cloned SKB isreleased while the merging is in process, from_shinfo->nr_frags will beset to 0 toward the end of the function, causing the increment of fragpage _refcount to be unexpectedly skipped resulting in inconsistentreference counts. Later when SKB(@to) is released, it frees the pagedirectly even though the page pool page is still in use, leading touse-after-free or double-free errors. So it should be prohibited.The double-free error message below prompted us to investigate:BUG: Bad page state in process swapper/1 pfn:0e0d1page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000index:0x2 pfn:0xe0d1flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)raw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000raw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000page dumped because: nonzero _refcountCPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 6.2.0+Call Trace: dump_stack_lvl+0x32/0x50bad_page+0x69/0xf0free_pcp_prepare+0x260/0x2f0free_unref_page+0x20/0x1c0skb_release_data+0x10b/0x1a0napi_consume_skb+0x56/0x150net_rx_action+0xf0/0x350? __napi_schedule+0x79/0x90__do_softirq+0xc8/0x2b1__irq_exit_rcu+0xb9/0xf0common_interrupt+0x82/0xa0asm_common_interrupt+0x22/0x40RIP: 0010:default_idle+0xb/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53188 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix race on port outputassume the following setup on a single machine:1. An openvswitch instance with one bridge and default flows2. two network namespaces "server" and "client"3. two ovs interfaces "server" and "client" on the bridge4. for each ovs interface a veth pair with a matching name and 32 rx and tx queues5. move the ends of the veth pairs to the respective network namespaces6. assign ip addresses to each of the veth ends in the namespaces (needs to be the same subnet)7. start some http server on the server network namespace8. test if a client in the client namespace can reach the http serverwhen following the actions below the host has a chance of getting a cpustuck in a infinite loop:1. send a large amount of parallel requests to the http server (around 3000 curls should work)2. in parallel delete the network namespace (do not delete interfaces or stop the server, just kill the namespace)there is a low chance that this will cause the below kernel cpu stuckmessage. If this does not happen just retry.Below there is also the output of bpftrace for the functions mentionedin the output.The series of events happening here is:1. the network namespace is deleted calling `unregister_netdevice_many_notify` somewhere in the process2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and then runs `synchronize_net`3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER`4. this is then handled by `dp_device_event` which calls `ovs_netdev_detach_dev` (if a vport is found, which is the case for the veth interface attached to ovs)5. this removes the rx_handlers of the device but does not prevent packages to be sent to the device6. `dp_device_event` then queues the vport deletion to work in background as a ovs_lock is needed that we do not hold in the unregistration path7. `unregister_netdevice_many_notify` continues to call `netdev_unregister_kobject` which sets `real_num_tx_queues` to 08. port deletion continues (but details are not relevant for this issue)9. at some future point the background task deletes the vportIf after 7. but before 9. a packet is send to the ovs vport (which isnot deleted at this point in time) which forwards it to the`dev_queue_xmit` flow even though the device is unregistering.In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there isa while loop (if the packet has a rx_queue recorded) that is infinite if`dev->real_num_tx_queues` is zero.To prevent this from happening we update `do_output` to handle deviceswithout carrier the same as if the device is not found (which wouldbe the code path after 9. is done).Additionally we now produce a warning in `skb_tx_hash` if we will hitthe infinite loop.bpftrace (first word is function name):__dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2dp_---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53189 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6/addrconf: fix a potential refcount underflow for idevNow in addrconf_mod_rs_timer(), reference idev depends on whetherrs_timer is not pending. Then modify rs_timer timeout.There is a time gap in [1], during which if the pending rs_timerbecomes not pending. It will miss to hold idev, but the rs_timeris activated. Thus rs_timer callback function addrconf_rs_timer()will be executed and put idev later without holding idev. A refcountunderflow issue for idev can be caused by this. if (!timer_pending(&idev->rs_timer)) in6_dev_hold(idev); <--------------[1] mod_timer(&idev->rs_timer, jiffies + when);To fix the issue, hold idev if mod_timer() return 0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53191 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domainsof_irq_find_parent() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53192 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Fix nexthop hash sizeThe nexthop code expects a 31 bit hash, such as what is returned byfib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hashreturned by skb_get_hash() can lead to problems related to the fact that'int hash' is a negative number when the MSB is set.In the case of hash threshold nexthop groups, nexthop_select_path_hthr()will disproportionately select the first nexthop group entry. In the caseof resilient nexthop groups, nexthop_select_path_res() may do an out ofbounds access in nh_buckets[], for example: hash = -912054133 num_nh_buckets = 2 bucket_index = 65535which leads to the following panic:BUG: unable to handle page fault for address: ffffc900025910c8PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0Oops: 0002 [#1] PREEMPT SMP KASAN NOPTICPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014Workqueue: ipv6_addrconf addrconf_dad_workRIP: 0010:nexthop_select_path+0x197/0xbf0Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85RSP: 0018:ffff88810c36f260 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0PKRU: 55555554Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x1ee/0x5c0 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? __pfx_page_fault_oops+0x10/0x10 ? search_bpf_extables+0xfe/0x1c0 ? fixup_exception+0x3b/0x470 ? exc_page_fault+0xf6/0x110 ? asm_exc_page_fault+0x26/0x30 ? nexthop_select_path+0x197/0xbf0 ? nexthop_select_path+0x197/0xbf0 ? lock_is_held_type+0xe7/0x140 vxlan_xmit+0x5b2/0x2340 ? __lock_acquire+0x92b/0x3370 ? __pfx_vxlan_xmit+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ? __pfx_register_lock_class+0x10/0x10 ? skb_network_protocol+0xce/0x2d0 ? dev_hard_start_xmit+0xca/0x350 ? __pfx_vxlan_xmit+0x10/0x10 dev_hard_start_xmit+0xca/0x350 __dev_queue_xmit+0x513/0x1e20 ? __pfx___dev_queue_xmit+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? mark_held_locks+0x44/0x90 ? skb_push+0x4c/0x80 ? eth_header+0x81/0xe0 ? __pfx_eth_header+0x10/0x10 ? neigh_resolve_output+0x215/0x310 ? ip6_finish_output2+0x2ba/0xc90 ip6_finish_output2+0x2ba/0xc90 ? lock_release+0x236/0x3e0 ? ip6_mtu+0xbb/0x240 ? __pfx_ip6_finish_output2+0x10/0x10 ? find_held_lock+0x83/0xa0 ? lock_is_held_type+0xe7/0x140 ip6_finish_output+0x1ee/0x780 ip6_output+0x138/0x460 ? __pfx_ip6_output+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ? __pfx_ip6_finish_output+0x10/0x10 NF_HOOK.constprop.0+0xc0/0x420 ? __pfx_NF_HOOK.constprop.0+0x10/0x10 ? ndisc_send_skb+0x2c0/0x960 ? __pfx_lock_release+0x10/0x10 ? __local_bh_enable_ip+0x93/0x110 ? lock_is_held_type+0xe7/0x140 ndisc_send_skb+0x4be/0x960 ? __pfx_ndisc_send_skb+0x10/0x10 ? mark_held_locks+0x65/0x90 ? find_held_lock+0x83/0xa0 ndisc_send_ns+0xb0/0x110 ? __pfx_ndisc_send_ns+0x10/0x10 addrconf_dad_work+0x631/0x8e0 ? lock_acquire+0x180/0x3f0 ? __pfx_addrconf_dad_work+0x10/0x10 ? mark_held_locks+0x24/0x90 process_one_work+0x582/0x9c0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x24/0x90 worker_thread+0x93/0x630 ? __kthread_parkme+0xdc/0x100 ? __pfx_worker_thread+0x10/0x10 kthread+0x1a5/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53202 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PM: domains: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53204 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data-races around user->unix_inflight.user->unix_inflight is changed under spin_lock(unix_gc_lock),but too_many_unix_fds() reads it locklessly.Let's annotate the write/read accesses to user->unix_inflight.BUG: KCSAN: data-race in unix_attach_fds / unix_inflightwrite to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1: unix_inflight+0x157/0x180 net/unix/scm.c:66 unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8read to 0xffffffff8546f2d0 of 8 bytes by task 44814 on cpu 0: too_many_unix_fds net/unix/scm.c:101 [inline] unix_attach_fds+0x54/0x1e0 net/unix/scm.c:110 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8value changed: 0x000000000000000c -> 0x000000000000000dReported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 44814 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53217 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nubus: Partially revert proc_create_single_data() conversionThe conversion to proc_create_single_data() introduced a regressionwhereby reading a file in /proc/bus/nubus results in a seg fault: # grep -r . /proc/bus/nubus/e/ Data read fault at 0x00000020 in Super Data (pc=0x1074c2) BAD KERNEL BUSERR Oops: 00000000 Modules linked in: PC: [<001074c2>] PDE_DATA+0xc/0x16 SR: 2010 SP: 38284958 a2: 01152370 d0: 00000001 d1: 01013000 d2: 01002790 d3: 00000000 d4: 00000001 d5: 0008ce2e a0: 00000000 a1: 00222a40 Process grep (pid: 45, task=142f8727) Frame format=B ssw=074d isc=2008 isb=4e5e daddr=00000020 dobuf=01199e70 baddr=001074c8 dibuf=ffffffff ver=f Stack from 01199e48: 01199e70 00222a58 01002790 00000000 011a3000 01199eb0 015000c0 00000000 00000000 01199ec0 01199ec0 000d551a 011a3000 00000001 00000000 00018000 d003f000 00000003 00000001 0002800d 01052840 01199fa8 c01f8000 00000000 00000029 0b532b80 00000000 00000000 00000029 0b532b80 01199ee4 00103640 011198c0 d003f000 00018000 01199fa8 00000000 011198c0 00000000 01199f4c 000b3344 011198c0 d003f000 00018000 01199fa8 00000000 00018000 011198c0 Call Trace: [<00222a58>] nubus_proc_rsrc_show+0x18/0xa0 [<000d551a>] seq_read+0xc4/0x510 [<00018000>] fp_fcos+0x2/0x82 [<0002800d>] __sys_setreuid+0x115/0x1c6 [<00103640>] proc_reg_read+0x5c/0xb0 [<00018000>] fp_fcos+0x2/0x82 [<000b3344>] __vfs_read+0x2c/0x13c [<00018000>] fp_fcos+0x2/0x82 [<00018000>] fp_fcos+0x2/0x82 [<000b8aa2>] sys_statx+0x60/0x7e [<000b34b6>] vfs_read+0x62/0x12a [<00018000>] fp_fcos+0x2/0x82 [<00018000>] fp_fcos+0x2/0x82 [<000b39c2>] ksys_read+0x48/0xbe [<00018000>] fp_fcos+0x2/0x82 [<000b3a4e>] sys_read+0x16/0x1a [<00018000>] fp_fcos+0x2/0x82 [<00002b84>] syscall+0x8/0xc [<00018000>] fp_fcos+0x2/0x82 [<0000c016>] not_ext+0xa/0x18 Code: 4e5e 4e75 4e56 0000 206e 0008 2068 ffe8 <2068> 0020 2008 4e5e 4e75 4e56 0000 2f0b 206e 0008 2068 0004 2668 0020 206b ffe8 Disabling lock debugging due to kernel taint Segmentation faultThe proc_create_single_data() conversion does not work becausesingle_open(file, nubus_proc_rsrc_show, PDE_DATA(inode)) is notequivalent to the original code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53218 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Make it so that a waiting process can be abortedWhen sendmsg() creates an rxrpc call, it queues it to wait for a connectionand channel to be assigned and then waits before it can start shovellingdata as the encrypted DATA packet content includes a summary of theconnection parameters.However, sendmsg() may get interrupted before a connection gets assignedand further sendmsg() calls will fail with EBUSY until an assignment ismade.Fix this so that the call can at least be aborted without failing onEBUSY. We have to be careful here as sendmsg() mustn't be allowed to startthe call timer if the call doesn't yet have a connection assigned as anoops may follow shortly thereafter.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53221 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix memleak due to fentry attach failureIf it fails to attach fentry, the allocated bpf trampoline image will beleft in the system. That can be verified by checking /proc/kallsyms.This meamleak can be verified by a simple bpf program as follows: SEC("fentry/trap_init") int fentry_run() { return 0; }It will fail to attach trap_init because this function is freed afterkernel init, and then we can find the trampoline image is left in thesystem by checking /proc/kallsyms. $ tail /proc/kallsyms ffffffffc0613000 t bpf_trampoline_6442453466_1 [bpf] ffffffffc06c3000 t bpf_trampoline_6442453466_1 [bpf] $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "FUNC 'trap_init'" [2522] FUNC 'trap_init' type_id=119 linkage=static $ echo $((6442453466 & 0x7fffffff)) 2522Note that there are two left bpf trampoline images, that is because thelibbpf will fallback to raw tracepoint if -EINVAL is returned.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53224 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: Fix function prototype mismatch for ext4_feat_ktypeWith clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),indirect call targets are validated against the expected functionpointer prototype to make sure the call target is valid to help mitigateROP attacks. If they are not identical, there is a failure at run time,which manifests as either a kernel panic or thread getting killed.ext4_feat_ktype was setting the "release" handler to "kfree", whichdoesn't have a matching function prototype. Add a simple wrapperwith the correct prototype.This was found as a result of Clang's new -Wcast-function-type-strictflag, which is more sensitive than the simpler -Wcast-function-type,which only checks for type width mismatches.Note that this code is only reached when ext4 is a loadable module andit is being unloaded: CFI failure at kobject_put+0xbb/0x1b0 (target: kfree+0x0/0x180; expected type: 0x7c4aa698) ... RIP: 0010:kobject_put+0xbb/0x1b0 ... Call Trace: ext4_exit_sysfs+0x14/0x60 [ext4] cleanup_module+0x67/0xedb [ext4]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53231 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: Fix detection of atomic contextCurrent check for atomic context is not sufficient asz_erofs_decompressqueue_endio can be called under rcu lockfrom blk_mq_flush_plug_list(). See the stacktrace [1]In such case we should hand off the decompression work for asyncprocessing rather than trying to do sync decompression in currentcontext. Patch fixes the detection by checking forrcu_read_lock_any_held() and while at it use more appropriate!in_task() check than in_atomic().Background: Historically erofs would always schedule a kworker fordecompression which would incur the scheduling cost regardless ofthe context. But z_erofs_decompressqueue_endio() may not alwaysbe in atomic context and we could actually benefit from doing thedecompression in z_erofs_decompressqueue_endio() if we are inthread context, for example when running with dm-verity.This optimization was later added in patch [2] which has shownimprovement in performance benchmarks.==============================================[1] Problem stacktrace[name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291[name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi[name:core&]preempt_count: 0, expected: 0[name:core&]RCU nest depth: 1, expected: 0CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1Hardware name: MT6897 (DT)Call trace: dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48 __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4[2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53233 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix deadlock triggered by cancel_delayed_work_syn()The following LOCKDEP was detected: Workqueue: events smc_lgr_free_work [smc] WARNING: possible circular locking dependency detected 6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted ------------------------------------------------------ kworker/3:0/176251 is trying to acquire lock: 00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}, at: __flush_workqueue+0x7a/0x4f0 but task is already holding lock: 0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_work+0x76/0xf0 __cancel_work_timer+0x170/0x220 __smc_lgr_terminate.part.0+0x34/0x1c0 [smc] smc_connect_rdma+0x15e/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #3 (smc_client_lgr_pending){+.+.}-{3:3}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __mutex_lock+0x96/0x8e8 mutex_lock_nested+0x32/0x40 smc_connect_rdma+0xa4/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 lock_sock_nested+0x46/0xa8 smc_tx_work+0x34/0x50 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 process_one_work+0x2bc/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}: check_prev_add+0xd8/0xe88 validate_chain+0x70c/0xb20 __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_workqueue+0xaa/0x4f0 drain_workqueue+0xaa/0x158 destroy_workqueue+0x44/0x2d8 smc_lgr_free+0x9e/0xf8 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 other info that might help us debug this: Chain exists of: (wq_completion)smc_tx_wq-00000000#2 --> smc_client_lgr_pending --> (work_completion)(&(&lgr->free_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&(&lgr->free_work)->work)); lock(smc_client_lgr_pending); lock((work_completion) (&(&lgr->free_work)->work)); lock((wq_completion)smc_tx_wq-00000000#2); *** DEADLOCK *** 2 locks held by kworker/3:0/176251: #0: 0000000080183548 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x232/0x730 #1: 0000037fffe97dc8 ((work_completion) (&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 stack backtr---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53247 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set_page_extent_mapped after read_folio in btrfs_cont_expandWhile trying to get the subpage blocksize tests running, I hit thefollowing panic on generic/476 assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_clear_checked+0x38/0xc0 btrfs_page_clear_checked+0x48/0x98 btrfs_truncate_block+0x5d0/0x6a8 btrfs_cont_expand+0x5c/0x528 btrfs_write_check.isra.0+0xf8/0x150 btrfs_buffered_write+0xb4/0x760 btrfs_do_write_iter+0x2f8/0x4b0 btrfs_file_write_iter+0x1c/0x30 do_iter_readv_writev+0xc8/0x158 do_iter_write+0x9c/0x210 vfs_iter_write+0x24/0x40 iter_file_splice_write+0x224/0x390 direct_splice_actor+0x38/0x68 splice_direct_to_actor+0x12c/0x260 do_splice_direct+0x90/0xe8 generic_copy_file_range+0x50/0x90 vfs_copy_file_range+0x29c/0x470 __arm64_sys_copy_file_range+0xcc/0x498 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x168 el0_svc+0x50/0x1b0 el0t_64_sync_handler+0x114/0x120 el0t_64_sync+0x194/0x198This happens because during btrfs_cont_expand we'll get a page, set itas mapped, and if it's not Uptodate we'll read it. However between theread and re-locking the page we could have called release_folio() on thepage, but left the page in the file mapping. release_folio() can clearthe page private, and thus further down we blow up when we go to modifythe subpage bits.Fix this by putting the set_page_extent_mapped() after the read. Thisis safe because read_folio() will call set_page_extent_mapped() beforeit does the read, and then if we clear page private but leave it on themapping we're completely safe re-setting set_page_extent_mapped(). Withthis patch I can now run generic/476 without panicing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53287 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: Put the cdns set active part outside the spin lockThe device may be scheduled during the resume process,so this cannot appear in atomic operations. Sincepm_runtime_set_active will resume suppliers, put setactive outside the spin lock, which is only used toprotect the struct cdns data structure, otherwise thekernel will report the following warning: BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1163 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 651, name: sh preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 PID: 651 Comm: sh Tainted: G WC 6.1.20 #1 Hardware name: Freescale i.MX8QM MEK (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x64/0x80 dump_stack+0x1c/0x38 __might_resched+0x1fc/0x240 __might_sleep+0x68/0xc0 __pm_runtime_resume+0x9c/0xe0 rpm_get_suppliers+0x68/0x1b0 __pm_runtime_set_status+0x298/0x560 cdns_resume+0xb0/0x1c0 cdns3_controller_resume.isra.0+0x1e0/0x250 cdns3_plat_resume+0x28/0x40

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53289 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: bdisp: Add missing check for create_workqueueAdd the check for the return value of the create_workqueuein order to avoid NULL pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53291 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcu/rcuscale: Stop kfree_scale_thread thread(s) after unloading rcuscaleRunning the 'kfree_rcu_test' test case [1] results in a splat [2].The root cause is the kfree_scale_thread thread(s) continue runningafter unloading the rcuscale module. This commit fixes that isue byinvoking kfree_scale_cleanup() from rcu_scale_cleanup() when removingthe rcuscale module.[1] modprobe rcuscale kfree_rcu_test=1 // After some time rmmod rcuscale rmmod torture[2] BUG: unable to handle page fault for address: ffffffffc0601a87 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 11de4f067 P4D 11de4f067 PUD 11de51067 PMD 112f4d067 PTE 0 Oops: 0010 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1798 Comm: kfree_scale_thr Not tainted 6.3.0-rc1-rcu+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:0xffffffffc0601a87 Code: Unable to access opcode bytes at 0xffffffffc0601a5d. RSP: 0018:ffffb25bc2e57e18 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffffffffc061f0b6 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff962fd0de RDI: ffffffff962fd0de RBP: ffffb25bc2e57ea8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000000 R14: 000000000000000a R15: 00000000001c1dbe FS: 0000000000000000(0000) GS:ffff921fa2200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc0601a5d CR3: 000000011de4c006 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? kvfree_call_rcu+0xf0/0x3a0 ? kthread+0xf3/0x120 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x1f/0x30 Modules linked in: rfkill sunrpc ... [last unloaded: torture] CR2: ffffffffc0601a87 ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53308 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fec: Better handle pm_runtime_get() failing in .remove()In the (unlikely) event that pm_runtime_get() (disguised aspm_runtime_resume_and_get()) fails, the remove callback returned anerror early. The problem with this is that the driver core ignores theerror value and continues removing the device. This results in aresource leak. Worse the devm allocated resources are freed and so if acallback of the driver is called later the register mapping is alreadygone which probably results in a crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53318 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:recordmcount: Fix memory leaks in the uwrite functionCommon realloc mistake: 'file_append' nulled but not freed upon failure

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53332 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask()If ipi_send_{mask|single}() is called with an invalid interrupt number, allthe local variables there will be NULL. ipi_send_verify() which is invokedfrom these functions does verify its 'data' parameter, resulting in akernel oops in irq_data_get_affinity_mask() as the passed NULL pointer getsdereferenced.Add a missing NULL pointer check in ipi_send_verify()...Found by Linux Verification Center (linuxtesting.org) with the SVACE staticanalysis tool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53339 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix BUG_ON condition in btrfs_cancel_balancePausing and canceling balance can race to interrupt balance lead to BUG_ONpanic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balancedoes not take this race scenario into account.However, the race condition has no other side effects. We can fix that.Reproducing it with panic trace like this: kernel BUG at fs/btrfs/volumes.c:4618! RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0 Call Trace: ? do_nanosleep+0x60/0x120 ? hrtimer_nanosleep+0xb7/0x1a0 ? sched_core_clone_cookie+0x70/0x70 btrfs_ioctl_balance_ctl+0x55/0x70 btrfs_ioctl+0xa46/0xd20 __x64_sys_ioctl+0x7d/0xa0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Race scenario as follows: > mutex_unlock(&fs_info->balance_mutex); > -------------------- > .......issue pause and cancel req in another thread > -------------------- > ret = __btrfs_balance(fs_info); > > mutex_lock(&fs_info->balance_mutex); > if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req)) { > btrfs_info(fs_info, "balance: paused"); > btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED); > }

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53343 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:icmp6: Fix null-ptr-deref of ip6_null_entry->rt6i_idev in icmp6_dev().With some IPv6 Ext Hdr (RPL, SRv6, etc.), we can send a packet thathas the link-local address as src and dst IP and will be forwarded toan external IP in the IPv6 Ext Hdr.For example, the script below generates a packet whose src IP is thelink-local address and dst is updated to 11::. # for f in $(find /proc/sys/net/ -name *seg6_enabled*); do echo 1 > $f; done # python3 >>> from socket import * >>> from scapy.all import * >>> >>> SRC_ADDR = DST_ADDR = "fe80::5054:ff:fe12:3456" >>> >>> pkt = IPv6(src=SRC_ADDR, dst=DST_ADDR) >>> pkt /= IPv6ExtHdrSegmentRouting(type=4, addresses=["11::", "22::"], segleft=1) >>> >>> sk = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW) >>> sk.sendto(bytes(pkt), (DST_ADDR, 0))For such a packet, we call ip6_route_input() to look up a route for thenext destination in these three functions depending on the header type. * ipv6_rthdr_rcv() * ipv6_rpl_srh_rcv() * ipv6_srh_rcv()If no route is found, ip6_null_entry is set to skb, and the followingdst_input(skb) calls ip6_pkt_drop().Finally, in icmp6_dev(), we dereference skb_rt6_info(skb)->rt6i_idev->devas the input device is the loopback interface. Then, we have to check ifskb_rt6_info(skb)->rt6i_idev is NULL or not to avoid NULL pointer dereffor ip6_null_entry.BUG: kernel NULL pointer dereference, address: 0000000000000000 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP PTICPU: 0 PID: 157 Comm: python3 Not tainted 6.4.0-11996-gb121d614371c #35Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:icmp6_send (net/ipv6/icmp.c:436 net/ipv6/icmp.c:503)Code: fe ff ff 48 c7 40 30 c0 86 5d 83 e8 c6 44 1c 00 e9 c8 fc ff ff 49 8b 46 58 48 83 e0 fe 0f 84 4a fb ff ff 48 8b 80 d0 00 00 00 <48> 8b 00 44 8b 88 e0 00 00 00 e9 34 fb ff ff 4d 85 ed 0f 85 69 01RSP: 0018:ffffc90000003c70 EFLAGS: 00000286RAX: 0000000000000000 RBX: 0000000000000001 RCX: 00000000000000e0RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff888006d72a18RBP: ffffc90000003d80 R08: 0000000000000000 R09: 0000000000000001R10: ffffc90000003d98 R11: 0000000000000040 R12: ffff888006d72a10R13: 0000000000000000 R14: ffff8880057fb800 R15: ffffffff835d86c0FS: 00007f9dc72ee740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 00000000057b2000 CR4: 00000000007506f0PKRU: 55555554Call Trace: ip6_pkt_drop (net/ipv6/route.c:4513) ipv6_rthdr_rcv (net/ipv6/exthdrs.c:640 net/ipv6/exthdrs.c:686) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:437 (discriminator 5)) ip6_input_finish (./include/linux/rcupdate.h:781 net/ipv6/ip6_input.c:483) __netif_receive_skb_one_core (net/core/dev.c:5455) process_backlog (./include/linux/rcupdate.h:781 net/core/dev.c:5895) __napi_poll (net/core/dev.c:6460) net_rx_action (net/core/dev.c:6529 net/core/dev.c:6660) __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) __local_bh_enable_ip (kernel/softirq.c:381) __dev_queue_xmit (net/core/dev.c:4231) ip6_finish_output2 (./include/net/neighbour.h:544 net/ipv6/ip6_output.c:135) rawv6_sendmsg (./include/net/dst.h:458 ./include/linux/netfilter.h:303 net/ipv6/raw.c:656 net/ipv6/raw.c:914) sock_sendmsg (net/socket.c:725 net/socket.c:748) __sys_sendto (net/socket.c:2134) __x64_sys_sendto (net/socket.c:2146 net/socket.c:2142 net/socket.c:2142) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)RIP: 0033:0x7f9dc751baeaCode: d8 64 89 02 48 c7 c0 ff f---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53346 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kernel/fail_function: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53347 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Handle pairing of E-switch via uplink un/load APIsIn case user switch a device from switchdev mode to legacy mode, mlx5first unpair the E-switch and afterwards unload the uplink vport.From the other hand, in case user remove or reload a device, mlx5first unload the uplink vport and afterwards unpair the E-switch.The latter is causing a bug[1], hence, handle pairing of E-switch aspart of uplink un/load APIs.[1]In case VF_LAG is used, every tc fdb flow is duplicated to the peeresw. However, the original esw keeps a pointer to this duplicatedflow, not the peer esw.e.g.: if user create tc fdb flow over esw0, the flow is duplicatedover esw1, in FW/HW, but in SW, esw0 keeps a pointer to the duplicatedflow.During module unload while a peer tc fdb flow is still offloaded, incase the first device to be removed is the peer device (esw1 in theexample above), the peer net-dev is destroyed, and so the mlx5e_privis memset to 0.Afterwards, the peer device is trying to unpair himself from theoriginal device (esw0 in the example above). Unpair API invoke theoriginal device to clear peer flow from its eswitch (esw0), but thepeer flow, which is stored over the original eswitch (esw0), istrying to use the peer mlx5e_priv, which is memset to 0 and result inbellow kernel-oops.[ 157.964081 ] BUG: unable to handle page fault for address: 000000000002ce60[ 157.964662 ] #PF: supervisor read access in kernel mode[ 157.965123 ] #PF: error_code(0x0000) - not-present page[ 157.965582 ] PGD 0 P4D 0[ 157.965866 ] Oops: 0000 [#1] SMP[ 157.967670 ] RIP: 0010:mlx5e_tc_del_fdb_flow+0x48/0x460 [mlx5_core][ 157.976164 ] Call Trace:[ 157.976437 ] [ 157.976690 ] __mlx5e_tc_del_fdb_peer_flow+0xe6/0x100 [mlx5_core][ 157.977230 ] mlx5e_tc_clean_fdb_peer_flows+0x67/0x90 [mlx5_core][ 157.977767 ] mlx5_esw_offloads_unpair+0x2d/0x1e0 [mlx5_core][ 157.984653 ] mlx5_esw_offloads_devcom_event+0xbf/0x130 [mlx5_core][ 157.985212 ] mlx5_devcom_send_event+0xa3/0xb0 [mlx5_core][ 157.985714 ] esw_offloads_disable+0x5a/0x110 [mlx5_core][ 157.986209 ] mlx5_eswitch_disable_locked+0x152/0x170 [mlx5_core][ 157.986757 ] mlx5_eswitch_disable+0x51/0x80 [mlx5_core][ 157.987248 ] mlx5_unload+0x2a/0xb0 [mlx5_core][ 157.987678 ] mlx5_uninit_one+0x5f/0xd0 [mlx5_core][ 157.988127 ] remove_one+0x64/0xe0 [mlx5_core][ 157.988549 ] pci_device_remove+0x31/0xa0[ 157.988933 ] device_release_driver_internal+0x18f/0x1f0[ 157.989402 ] driver_detach+0x3f/0x80[ 157.989754 ] bus_remove_driver+0x70/0xf0[ 157.990129 ] pci_unregister_driver+0x34/0x90[ 157.990537 ] mlx5_cleanup+0xc/0x1c [mlx5_core][ 157.990972 ] __x64_sys_delete_module+0x15a/0x250[ 157.991398 ] ? exit_to_user_mode_prepare+0xea/0x110[ 157.991840 ] do_syscall_64+0x3d/0x90[ 157.992198 ] entry_SYSCALL_64_after_hwframe+0x46/0xb0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53348 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix deadlock when aborting transaction during relocation with scrubBefore relocating a block group we pause scrub, then do the relocation andthen unpause scrub. The relocation process requires starting and committinga transaction, and if we have a failure in the critical section of thetransaction commit path (transaction state >= TRANS_STATE_COMMIT_START),we will deadlock if there is a paused scrub.That results in stack traces like the following: [42.479] BTRFS info (device sdc): relocating block group 53876686848 flags metadata|raid6 [42.936] BTRFS warning (device sdc): Skipping commit of aborted transaction. [42.936] ------------[ cut here ]------------ [42.936] BTRFS: Transaction aborted (error -28) [42.936] WARNING: CPU: 11 PID: 346822 at fs/btrfs/transaction.c:1977 btrfs_commit_transaction+0xcc8/0xeb0 [btrfs] [42.936] Modules linked in: dm_flakey dm_mod loop btrfs (...) [42.936] CPU: 11 PID: 346822 Comm: btrfs Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1 [42.936] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [42.936] RIP: 0010:btrfs_commit_transaction+0xcc8/0xeb0 [btrfs] [42.936] Code: ff ff 45 8b (...) [42.936] RSP: 0018:ffffb58649633b48 EFLAGS: 00010282 [42.936] RAX: 0000000000000000 RBX: ffff8be6ef4d5bd8 RCX: 0000000000000000 [42.936] RDX: 0000000000000002 RSI: ffffffffb35e7782 RDI: 00000000ffffffff [42.936] RBP: ffff8be6ef4d5c98 R08: 0000000000000000 R09: ffffb586496339e8 [42.936] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8be6d38c7c00 [42.936] R13: 00000000ffffffe4 R14: ffff8be6c268c000 R15: ffff8be6ef4d5cf0 [42.936] FS: 00007f381a82b340(0000) GS:ffff8beddfcc0000(0000) knlGS:0000000000000000 [42.936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42.936] CR2: 00007f1e35fb7638 CR3: 0000000117680006 CR4: 0000000000370ee0 [42.936] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42.936] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42.936] Call Trace: [42.936] [42.936] ? start_transaction+0xcb/0x610 [btrfs] [42.936] prepare_to_relocate+0x111/0x1a0 [btrfs] [42.936] relocate_block_group+0x57/0x5d0 [btrfs] [42.936] ? btrfs_wait_nocow_writers+0x25/0xb0 [btrfs] [42.936] btrfs_relocate_block_group+0x248/0x3c0 [btrfs] [42.936] ? __pfx_autoremove_wake_function+0x10/0x10 [42.936] btrfs_relocate_chunk+0x3b/0x150 [btrfs] [42.936] btrfs_balance+0x8ff/0x11d0 [btrfs] [42.936] ? __kmem_cache_alloc_node+0x14a/0x410 [42.936] btrfs_ioctl+0x2334/0x32c0 [btrfs] [42.937] ? mod_objcg_state+0xd2/0x360 [42.937] ? refill_obj_stock+0xb0/0x160 [42.937] ? seq_release+0x25/0x30 [42.937] ? __rseq_handle_notify_resume+0x3b5/0x4b0 [42.937] ? percpu_counter_add_batch+0x2e/0xa0 [42.937] ? __x64_sys_ioctl+0x88/0xc0 [42.937] __x64_sys_ioctl+0x88/0xc0 [42.937] do_syscall_64+0x38/0x90 [42.937] entry_SYSCALL_64_after_hwframe+0x72/0xdc [42.937] RIP: 0033:0x7f381a6ffe9b [42.937] Code: 00 48 89 44 24 (...) [42.937] RSP: 002b:00007ffd45ecf060 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [42.937] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f381a6ffe9b [42.937] RDX: 00007ffd45ecf150 RSI: 00000000c4009420 RDI: 0000000000000003 [42.937] RBP: 0000000000000003 R08: 0000000000000013 R09: 0000000000000000 [42.937] R10: 00007f381a60c878 R11: 0000000000000246 R12: 00007ffd45ed0423 [42.937] R13: 00007ffd45ecf150 R14: 0000000000000000 R15: 00007ffd45ecf148 [42.937] [42.937] ---[ end trace 0000000000000000 ]--- [42.937] BTRFS: error (device sdc: state A) in cleanup_transaction:1977: errno=-28 No space left [59.196] INFO: task btrfs:346772 blocked for more than 120 seconds. [59.196] Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1 [59.196] "echo 0 > /proc/sys/kernel/hung_---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53353 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:accel/habanalabs: postpone mem_mgr IDR destruction to hpriv_release()The memory manager IDR is currently destroyed when user releases thefile descriptor.However, at this point the user context might be still held, and memorybuffers might be still in use.Later on, calls to release those buffers will fail due to not findingtheir handles in the IDR, leading to a memory leak.To avoid this leak, split the IDR destruction from the memory managerfini, and postpone it to hpriv_release() when there is no user contextand no buffers are used.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53354 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:skbuff: skb_segment, Call zero copy functions before using skbuff fragsCommit bf5c25d60861 ("skbuff: in skb_segment, call zerocopy functionsonce per nskb") added the call to zero copy functions in skb_segment().The change introduced a bug in skb_segment() because skb_orphan_frags()may possibly change the number of fragments or allocate new fragmentsaltogether leaving nrfrags and frag to point to the old values. This cancause a panic with stacktrace like the one below.[ 193.894380] BUG: kernel NULL pointer dereference, address: 00000000000000bc[ 193.895273] CPU: 13 PID: 18164 Comm: vh-net-17428 Kdump: loaded Tainted: G O 5.15.123+ #26[ 193.903919] RIP: 0010:skb_segment+0xb0e/0x12f0[ 194.021892] Call Trace:[ 194.027422] [ 194.072861] tcp_gso_segment+0x107/0x540[ 194.082031] inet_gso_segment+0x15c/0x3d0[ 194.090783] skb_mac_gso_segment+0x9f/0x110[ 194.095016] __skb_gso_segment+0xc1/0x190[ 194.103131] netem_enqueue+0x290/0xb10 [sch_netem][ 194.107071] dev_qdisc_enqueue+0x16/0x70[ 194.110884] __dev_queue_xmit+0x63b/0xb30[ 194.121670] bond_start_xmit+0x159/0x380 [bonding][ 194.128506] dev_hard_start_xmit+0xc3/0x1e0[ 194.131787] __dev_queue_xmit+0x8a0/0xb30[ 194.138225] macvlan_start_xmit+0x4f/0x100 [macvlan][ 194.141477] dev_hard_start_xmit+0xc3/0x1e0[ 194.144622] sch_direct_xmit+0xe3/0x280[ 194.147748] __dev_queue_xmit+0x54a/0xb30[ 194.154131] tap_get_user+0x2a8/0x9c0 [tap][ 194.157358] tap_sendmsg+0x52/0x8e0 [tap][ 194.167049] handle_tx_zerocopy+0x14e/0x4c0 [vhost_net][ 194.173631] handle_tx+0xcd/0xe0 [vhost_net][ 194.176959] vhost_worker+0x76/0xb0 [vhost][ 194.183667] kthread+0x118/0x140[ 194.190358] ret_from_fork+0x1f/0x30[ 194.193670] In this case calling skb_orphan_frags() updated nr_frags leaving nrfragslocal variable in skb_segment() stale. This resulted in the code hittingi >= nrfrags prematurely and trying to move to next frag_skb usinglist_skb pointer, which was NULL, and caused kernel panic. Move the callto zero copy functions before using frags and nr_frags.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53355 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:staging: pi433: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once. This requires saving off the root directory dentry to makecreation of individual device subdirectories easier.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53367 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:accel/habanalabs: fix mem leak in capture user mappingsThis commit fixes a memory leak caused when clearing the user_mappingsinfo when a new context is opened immediately after user_mapping iscaptured and a hard reset is performed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53369 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dcb: choose correct policy to parse DCB_ATTR_BCNThe dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN],which is introduced in commit 859ee3c43812 ("DCB: Add support for DCBBCN"). Please see the comment in below codestatic int dcbnl_bcn_setcfg(...){ ... ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. ) // !!! dcbnl_pfc_up_nest for attributes // DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs ... for (i = DCB_BCN_ATTR_RP_0; i <= DCB_BCN_ATTR_RP_7; i++) { // !!! DCB_BCN_ATTR_RP_0 to DCB_BCN_ATTR_RP_7 in enum dcbnl_bcn_attrs ... value_byte = nla_get_u8(data[i]); ... } ... for (i = DCB_BCN_ATTR_BCNA_0; i <= DCB_BCN_ATTR_RI; i++) { // !!! DCB_BCN_ATTR_BCNA_0 to DCB_BCN_ATTR_RI in enum dcbnl_bcn_attrs ... value_int = nla_get_u32(data[i]); ... } ...}That is, the nla_parse_nested_deprecated uses dcbnl_pfc_up_nestattributes to parse nlattr defined in dcbnl_pfc_up_attrs. But thefollowing access code fetch each nlattr as dcbnl_bcn_attrs attributes.By looking up the associated nla_policy for dcbnl_bcn_attrs. We can findthe beginning part of these two policies are "same".static const struct nla_policy dcbnl_pfc_up_nest[...] = { [DCB_PFC_UP_ATTR_0] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_1] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_2] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_3] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_4] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_5] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_6] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_7] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG},};static const struct nla_policy dcbnl_bcn_nest[...] = { [DCB_BCN_ATTR_RP_0] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_1] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_2] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_3] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_4] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_5] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_6] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_7] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG}, // from here is somewhat different [DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32}, ... [DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG},};Therefore, the current code is buggy and thisnla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and usethe adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0.Hence use the correct policy dcbnl_bcn_nest to parse the nestedtb[DCB_ATTR_BCN] TLV.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53371 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_createThe memory pointed to by the fs->any pointer is not freed in the errorpath of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak.Fix by freeing the memory in the error path, thereby making the error pathidentical to mlx5e_fs_tt_redirect_any_destroy().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53372 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: fix a potential overflow in sctp_ifwdtsn_skipCurrently, when traversing ifwdtsn skips with _sctp_walk_ifwdtsn, it onlychecks the pos against the end of the chunk. However, the data left forthe last pos may be < sizeof(struct sctp_ifwdtsn_skip), and dereferenceit as struct sctp_ifwdtsn_skip may cause coverflow.This patch fixes it by checking the pos against "the end of the chunk -sizeof(struct sctp_ifwdtsn_skip)" in sctp_ifwdtsn_skip, similar tosctp_fwdtsn_skip.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53376 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpi3mr: Use number of bits to manage bitmap sizesTo allocate bitmaps, the mpi3mr driver calculates sizes of bitmaps usingbyte as unit. However, bitmap helper functions assume that bitmaps areallocated using unsigned long as unit. This gap causes memory access beyondthe bitmap sizes and results in "BUG: KASAN: slab-out-of-bounds". The BUGwas observed at firmware download to eHBA-9600. Call trace indicated thatthe out-of-bounds access happened in find_first_zero_bit() called frommpi3mr_send_event_ack() for miroc->evtack_cmds_bitmap.To fix the BUG, do not use bytes to manage bitmap sizes. Instead, usenumber of bits, and call bitmap helper functions which take number of bitsas arguments. For memory allocation, call bitmap_zalloc() instead ofkzalloc() and krealloc(). For memory free, call bitmap_free() instead ofkfree(). For zero clear, call bitmap_clear() instead of memset().Remove three fields for bitmap byte sizes in struct scmd_priv which are nolonger required. Replace the field dev_handle_bitmap_sz withdev_handle_bitmap_bits to keep number of bits of removepend_bitmap acrossresize.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53382 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: Reset connection when trying to use SMCRv2 fails.We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. Itcan be reproduced by:- smc_run nginx- smc_run wrk -t 32 -c 500 -d 30 http://: BUG: kernel NULL pointer dereference, address: 0000000000000014 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP: 0018:ffffb8294b2d7c78 EFLAGS: 00010a06 RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000 R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180 R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib] ? smcr_buf_map_link+0x24b/0x290 [smc] ? __smc_buf_create+0x4ee/0x9b0 [smc] smc_clc_send_accept+0x4c/0xb0 [smc] smc_listen_work+0x346/0x650 [smc] ? __schedule+0x279/0x820 process_one_work+0x1e5/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 During the CLC handshake, server sequentially tries available SMCRv2and SMCRv1 devices in smc_listen_work().If an SMCRv2 device is found. SMCv2 based link group and link will beassigned to the connection. Then assumed that some buffer assignmenterrors happen later in the CLC handshake, such as RMB registrationfailure, server will give up SMCRv2 and try SMCRv1 device instead. Butthe resources assigned to the connection won't be reset.When server tries SMCRv1 device, the connection creation process willbe executed again. Since conn->lnk has been assigned when trying SMCRv2,it will not be set to the correct SMCRv1 link insmcr_lgr_conn_assign_link(). So in such situation, conn->lgr points tocorrect SMCRv1 link group but conn->lnk points to the SMCRv2 linkmistakenly.Then in smc_clc_send_confirm_accept(), conn->rmb_desc->mr[link->link_idx]will be accessed. Since the link->link_idx is not correct, the relatedMR may not have been initialized, so crash happens. | Try SMCRv2 device first | |-> conn->lgr: assign existed SMCRv2 link group; | |-> conn->link: assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC); | |-> sndbuf & RMB creation fails, quit; | | Try SMCRv1 device then | |-> conn->lgr: create SMCRv1 link group and assign; | |-> conn->link: keep SMCRv2 link mistakenly; | |-> sndbuf & RMB creation succeed, only RMB->mr[link_idx = 0] | initialized. | | Then smc_clc_send_confirm_accept() accesses | conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash. vThis patch tries to fix this by cleaning conn->lnk before assigninglink. In addition, it is better to reset the connection and clean theresources assigned if trying SMCRv2 failed in buffer creation orregistration.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53383 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4The T241 platform suffers from the T241-FABRIC-4 erratum which causesunexpected behavior in the GIC when multiple transactions are receivedsimultaneously from different sources. This hardware issue impactsNVIDIA server platforms that use more than two T241 chipsinterconnected. Each chip has support for 320 {E}SPIs.This issue occurs when multiple packets from different GICs areincorrectly interleaved at the target chip. The erratum text belowspecifies exactly what can cause multiple transfer packets susceptibleto interleaving and GIC state corruption. GIC state corruption canlead to a range of problems, including kernel panics, and unexpectedbehavior.>From the erratum text: "In some cases, inter-socket AXI4 Stream packets with multiple transfers, may be interleaved by the fabric when presented to ARM Generic Interrupt Controller. GIC expects all transfers of a packet to be delivered without any interleaving. The following GICv3 commands may result in multiple transfer packets over inter-socket AXI4 Stream interface: - Register reads from GICD_I* and GICD_N* - Register writes to 64-bit GICD registers other than GICD_IROUTERn* - ITS command MOVALL Multiple commands in GICv4+ utilize multiple transfer packets, including VMOVP, VMOVI, VMAPP, and 64-bit register accesses." This issue impacts system configurations with more than 2 sockets, that require multi-transfer packets to be sent over inter-socket AXI4 Stream interface between GIC instances on different sockets. GICv4 cannot be supported. GICv3 SW model can only be supported with the workaround. Single and Dual socket configurations are not impacted by this issue and support GICv3 and GICv4."Writing to the chip alias region of the GICD_In{E} registers exceptGICD_ICENABLERn has an equivalent effect as writing to the globaldistributor. The SPI interrupt deactivate path is not impacted bythe erratum.To fix this problem, implement a workaround that ensures read accessesto the GICD_In{E} registers are directed to the chip that owns theSPI, and disable GICv4.x features. To simplify code changes, thegic_configure_irq() function uses the same alias region for both readand write operations to GICD_ICFGR.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53387 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Fix device management cmd timeout flowIn the UFS error handling flow, the host will send a device management cmd(NOP OUT) to the device for link recovery. If this cmd times out andclearing the doorbell fails, ufshcd_wait_for_dev_cmd() will do nothing andreturn. hba->dev_cmd.complete struct is not set to NULL.When this happens, if cmd has been completed by device, then we will callcomplete() in __ufshcd_transfer_req_compl(). Because the complete struct isallocated on the stack, the following crash will occur: ipanic_die+0x24/0x38 [mrdump] die+0x344/0x748 arm64_notify_die+0x44/0x104 do_debug_exception+0x104/0x1e0 el1_dbg+0x38/0x54 el1_sync_handler+0x40/0x88 el1_sync+0x8c/0x140 queued_spin_lock_slowpath+0x2e4/0x3c0 __ufshcd_transfer_req_compl+0x3b0/0x1164 ufshcd_trc_handler+0x15c/0x308 ufshcd_host_reset_and_restore+0x54/0x260 ufshcd_reset_and_restore+0x28c/0x57c ufshcd_err_handler+0xeb8/0x1b6c process_one_work+0x288/0x964 worker_thread+0x4bc/0xc7c kthread+0x15c/0x264 ret_from_fork+0x10/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53391 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfsAs the ramfs-based tmpfs uses ramfs_init_fs_context() for theinit_fs_context method, which allocates fc->s_fs_info, use ramfs_kill_sb()to free it and avoid a memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53397 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:modpost: fix off by one in is_executable_section()The > comparison should be >= to prevent an out of bounds arrayaccess.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53401 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: kmem: fix a NULL pointer dereference in obj_stock_flush_required()KCSAN found an issue in obj_stock_flush_required():stock->cached_objcg can be reset between the check and dereference:==================================================================BUG: KCSAN: data-race in drain_all_stock / drain_obj_stockwrite to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0: drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306 refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340 obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 memcg_slab_free_hook mm/slab.h:587 [inline] __cache_free mm/slab.c:3373 [inline] __do_kmem_cache_free mm/slab.c:3577 [inline] kmem_cache_free+0x105/0x280 mm/slab.c:3602 __d_free fs/dcache.c:298 [inline] dentry_free fs/dcache.c:375 [inline] __dentry_kill+0x422/0x4a0 fs/dcache.c:621 dentry_kill+0x8d/0x1e0 dput+0x118/0x1f0 fs/dcache.c:913 __fput+0x3bf/0x570 fs/file_table.c:329 ____fput+0x15/0x20 fs/file_table.c:349 task_work_run+0x123/0x160 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171 exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296 do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1: obj_stock_flush_required mm/memcontrol.c:3319 [inline] drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361 try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 try_charge mm/memcontrol.c:2837 [inline] mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025 sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 __do_sys_setsockopt net/socket.c:2282 [inline] __se_sys_setsockopt net/socket.c:2279 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0xffff8881382d52c0 -> 0xffff888138893740Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023Fix it by using READ_ONCE()/WRITE_ONCE() for all accesses tostock->cached_objcg.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53408 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:trace/blktrace: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53411 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PM: EM: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53419 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Protect rcu_print_task_exp_stall() ->exp_tasks accessFor kernels built with CONFIG_PREEMPT_RCU=y, the following scenario canresult in a NULL-pointer dereference: CPU1 CPU2rcu_preempt_deferred_qs_irqrestore rcu_print_task_exp_stall if (special.b.blocked) READ_ONCE(rnp->exp_tasks) != NULL raw_spin_lock_rcu_node np = rcu_next_node_entry(t, rnp) if (&t->rcu_node_entry == rnp->exp_tasks) WRITE_ONCE(rnp->exp_tasks, np) .... raw_spin_unlock_irqrestore_rcu_node raw_spin_lock_irqsave_rcu_node t = list_entry(rnp->exp_tasks->prev, struct task_struct, rcu_node_entry) (if rnp->exp_tasks is NULL, this will dereference a NULL pointer)The problem is that CPU2 accesses the rcu_node structure's->exp_tasksfield without holding the rcu_node structure's ->lock and CPU2 didnot observe CPU1's change to rcu_node structure's ->exp_tasks in time.Therefore, if CPU1 sets rcu_node structure's->exp_tasks pointer to NULL,then CPU2 might dereference that NULL pointer.This commit therefore holds the rcu_node structure's ->lock whileaccessing that structure's->exp_tasks field.[ paulmck: Apply Frederic Weisbecker feedback. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53421 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats()When blkg_alloc() is called to allocate a blkcg_gq structurewith the associated blkg_iostat_set's, there are 2 fields withinblkg_iostat_set that requires proper initialization - blkg & sync.The former field was introduced by commit 3b8cc6298724 ("blk-cgroup:Optimize blkcg_rstat_flush()") while the later one was introduced bycommit f73316482977 ("blk-cgroup: reimplement basic IO stats usingcgroup rstat").Unfortunately those fields in the blkg_iostat_set's are not properlyre-initialized when they are cleared in v1's blkcg_reset_stats(). Thiscan lead to a kernel panic due to NULL pointer access of the blkgpointer. The missing initialization of sync is less problematic andcan be a problem in a debug kernel due to missing lockdep initialization.Fix these problems by re-initializing them after memory clearing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53423 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:objtool: Fix memory leak in create_static_call_sections()strdup() allocates memory for key_name. We need to release the memory inthe following error paths. Add free() to avoid memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53425 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: platform: mediatek: vpu: fix NULL ptr dereferenceIf pdev is NULL, then it is still dereferenced.This fixes this smatch warning:drivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer 'pdev'

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53429 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't check PageError in __extent_writepage__extent_writepage currenly sets PageError whenever any error happens,and the also checks for PageError to decide if to call error handling.This leads to very unclear responsibility for cleaning up on errors.In the VM and generic writeback helpers the basic idea is that onceI/O is fired off all error handling responsibility is delegated to theend I/O handler. But if that end I/O handler sets the PageError bit,and the submitter checks it, the bit could in some cases leak into thesubmission context for fast enough I/O.Fix this by simply not checking PageError and just using the localret variable to check for submission errors. This also fundamentallysolves the long problem documented in a comment in __extent_writepageby never leaking the error bit into the submission context.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53433 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: add vlan_get_protocol_and_depth() helperBefore blamed commit, pskb_may_pull() was used insteadof skb_header_pointer() in __vlan_get_protocol() and friends.Few callers depended on skb->head being populated with MAC header,syzbot caught one of them (skb_mac_gso_segment())Add vlan_get_protocol_and_depth() to make the intent clearerand use it where sensible.This is a more generic fix than commit e9d3f80935b6("net/af_packet: make sure to pull mac header") which wasdealing with a similar issue.kernel BUG at include/linux/skbuff.h:2655 !invalid opcode: 0000 [#1] SMP KASANCPU: 0 PID: 1441 Comm: syz-executor199 Not tainted 6.1.24-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023RIP: 0010:__skb_pull include/linux/skbuff.h:2655 [inline]RIP: 0010:skb_mac_gso_segment+0x68f/0x6a0 net/core/gro.c:136Code: fd 48 8b 5c 24 10 44 89 6b 70 48 c7 c7 c0 ae 0d 86 44 89 e6 e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41RSP: 0018:ffffc90001bd7520 EFLAGS: 00010286RAX: ffffffff8469736a RBX: ffff88810f31dac0 RCX: ffff888115a18b00RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc90001bd75e8 R08: ffffffff84697183 R09: fffff5200037adf9R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000012R13: 000000000000fee5 R14: 0000000000005865 R15: 000000000000fed7FS: 000055555633f300(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:[] __skb_gso_segment+0x32d/0x4c0 net/core/dev.c:3419[] skb_gso_segment include/linux/netdevice.h:4819 [inline][] validate_xmit_skb+0x3aa/0xee0 net/core/dev.c:3725[] __dev_queue_xmit+0x1332/0x3300 net/core/dev.c:4313[] dev_queue_xmit+0x17/0x20 include/linux/netdevice.h:3029[] packet_snd net/packet/af_packet.c:3111 [inline][] packet_sendmsg+0x49d2/0x6470 net/packet/af_packet.c:3142[] sock_sendmsg_nosec net/socket.c:716 [inline][] sock_sendmsg net/socket.c:736 [inline][] __sys_sendto+0x472/0x5f0 net/socket.c:2139[] __do_sys_sendto net/socket.c:2151 [inline][] __se_sys_sendto net/socket.c:2147 [inline][] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147[] do_syscall_x64 arch/x86/entry/common.c:50 [inline][] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80[] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53441 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: cpumap: Fix memory leak in cpu_map_update_elemSyzkaller reported a memory leak as follows:BUG: memory leakunreferenced object 0xff110001198ef748 (size 192): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 32 bytes): 00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00 ....J........... 00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff ........(....... backtrace: [] __cpu_map_entry_alloc+0xf7/0xb00 [] cpu_map_update_elem+0x2fe/0x3d0 [] bpf_map_update_value.isra.0+0x2bd/0x520 [] map_update_elem+0x4cb/0x720 [] __se_sys_bpf+0x8c3/0xb90 [] do_syscall_64+0x30/0x40 [] entry_SYSCALL_64_after_hwframe+0x61/0xc6BUG: memory leakunreferenced object 0xff110001198ef528 (size 192): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) 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 00 00 00 00 00 00 00 ................ backtrace: [] __cpu_map_entry_alloc+0x260/0xb00 [] cpu_map_update_elem+0x2fe/0x3d0 [] bpf_map_update_value.isra.0+0x2bd/0x520 [] map_update_elem+0x4cb/0x720 [] __se_sys_bpf+0x8c3/0xb90 [] do_syscall_64+0x30/0x40 [] entry_SYSCALL_64_after_hwframe+0x61/0xc6BUG: memory leakunreferenced object 0xff1100010fd93d68 (size 8): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace: [] kvmalloc_node+0x11e/0x170 [] __cpu_map_entry_alloc+0x2f0/0xb00 [] cpu_map_update_elem+0x2fe/0x3d0 [] bpf_map_update_value.isra.0+0x2bd/0x520 [] map_update_elem+0x4cb/0x720 [] __se_sys_bpf+0x8c3/0xb90 [] do_syscall_64+0x30/0x40 [] entry_SYSCALL_64_after_hwframe+0x61/0xc6In the cpu_map_update_elem flow, when kthread_stop is called beforecalling the threadfn of rcpu->kthread, since the KTHREAD_SHOULD_STOP bitof kthread has been set by kthread_stop, the threadfn of rcpu->kthreadwill never be executed, and rcpu->refcnt will never be 0, which willlead to the allocated rcpu, rcpu->queue and rcpu->queue->queue cannot bereleased.Calling kthread_stop before executing kthread's threadfn will return-EINTR. We can complete the release of memory resources in this state.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53445 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: Fix a refcount bug in qrtr_recvmsg()Syzbot reported a bug as following:refcount_t: addition on 0; use-after-free....RIP: 0010:refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25...Call Trace: __refcount_add include/linux/refcount.h:199 [inline] __refcount_inc include/linux/refcount.h:250 [inline] refcount_inc include/linux/refcount.h:267 [inline] kref_get include/linux/kref.h:45 [inline] qrtr_node_acquire net/qrtr/af_qrtr.c:202 [inline] qrtr_node_lookup net/qrtr/af_qrtr.c:398 [inline] qrtr_send_resume_tx net/qrtr/af_qrtr.c:1003 [inline] qrtr_recvmsg+0x85f/0x990 net/qrtr/af_qrtr.c:1070 sock_recvmsg_nosec net/socket.c:1017 [inline] sock_recvmsg+0xe2/0x160 net/socket.c:1038 qrtr_ns_worker+0x170/0x1700 net/qrtr/ns.c:688 process_one_work+0x991/0x15c0 kernel/workqueue.c:2390 worker_thread+0x669/0x1090 kernel/workqueue.c:2537It occurs in the concurrent scenario of qrtr_recvmsg() andqrtr_endpoint_unregister() as following: cpu0 cpu1qrtr_recvmsg qrtr_endpoint_unregisterqrtr_send_resume_tx qrtr_node_releaseqrtr_node_lookup mutex_lock(&qrtr_node_lock)spin_lock_irqsave(&qrtr_nodes_lock, ) refcount_dec_and_test(&node->ref) [node->ref == 0]radix_tree_lookup [node != NULL] __qrtr_node_releaseqrtr_node_acquire spin_lock_irqsave(&qrtr_nodes_lock, )kref_get(&node->ref) [WARNING] ... mutex_unlock(&qrtr_node_lock)Use qrtr_node_lock to protect qrtr_node_lookup() implementation, thisis actually improving the protection of node reference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53450 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: remove a BUG_ON in ext4_mb_release_group_pa()If a malicious fuzzer overwrites the ext4 superblock while it ismounted such that the s_first_data_block is set to a very largenumber, the calculation of the block group can underflow, and triggera BUG_ON check. Change this to be an ext4_warning so that we don'tcrash the kernel.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53460 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: fix memory leak in rtw_usb_probe()drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe()warn: 'hw' from ieee80211_alloc_hw() not released on lines: 811Fix this by modifying return to a goto statement.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53461 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: wait interruptibly for request completions on exitWHen the ring exits, cleanup is done and the final cancelation andwaiting on completions is done by io_ring_exit_work. That function isinvoked by kworker, which doesn't take any signals. Because of that, itdoesn't really matter if we wait for completions in TASK_INTERRUPTIBLEor TASK_UNINTERRUPTIBLE state. However, it does matter to the hung taskdetection checker!Normally we expect cancelations and completions to happen ratherquickly. Some test cases, however, will exit the ring and park theowning task stopped (eg via SIGSTOP). If the owning task needs to runtask_work to complete requests, then io_ring_exit_work won't make anyprogress until the task is runnable again. Hence io_ring_exit_work cantrigger the hung task detection, which is particularly problematic ifpanic-on-hung-task is enabled.As the ring exit doesn't take signals to begin with, have it waitinterruptibly rather than uninterruptibly. io_uring has a separatestuck-exit warning that triggers independently anyway, so we're notreally missing anything by making this switch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53466 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7915: fix memory leak in mt7915_mcu_exitAlways purge mcu skb queues in mt7915_mcu_exit routine even ifmt7915_firmware_state fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53470 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ionic: catch failure from devlink_allocAdd a check for NULL on the alloc return. If devlink_alloc() fails andwe try to use devlink_priv() on the NULL return, the kernel gets veryunhappy and panics. With this fix, the driver load will still fail,but at least it won't panic the kernel.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53477 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Add lwtunnel encap size of all siblings in nexthop calculationIn function rt6_nlmsg_size(), the length of nexthop is calculatedby multipling the nexthop length of fib6_info and the number ofsiblings. However if the fib6_info has no lwtunnel but the siblingshave lwtunnels, the nexthop length is less than it should be, andit will trigger a warning in inet6_rt_notify() as follows:WARNING: CPU: 0 PID: 6082 at net/ipv6/route.c:6180 inet6_rt_notify+0x120/0x130......Call Trace: fib6_add_rt2node+0x685/0xa30 fib6_add+0x96/0x1b0 ip6_route_add+0x50/0xd0 inet6_rtm_newroute+0x97/0xa0 rtnetlink_rcv_msg+0x156/0x3d0 netlink_rcv_skb+0x5a/0x110 netlink_unicast+0x246/0x350 netlink_sendmsg+0x250/0x4c0 sock_sendmsg+0x66/0x70 ___sys_sendmsg+0x7c/0xd0 __sys_sendmsg+0x5d/0xb0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcThis bug can be reproduced by script:ip -6 addr add 2002::2/64 dev ens2ip -6 route add 100::/64 via 2002::1 dev ens2 metric 100for i in 10 20 30 40 50 60 70;do ip link add link ens2 name ipv_$i type ipvlan ip -6 addr add 2002::$i/64 dev ipv_$i ifconfig ipv_$i updonefor i in 10 20 30 40 50 60;do ip -6 route append 100::/64 encap ip6 dst 2002::$i via 2002::1dev ipv_$i metric 100doneip -6 route append 100::/64 via 2002::1 dev ipv_70 metric 100This patch fixes it by adding nexthop_len of every siblings usingrt6_nh_nlmsg_size().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53480 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kobject: Add sanity check for kset->kobj.ktype in kset_register()When I register a kset in the following way: static struct kset my_kset; kobject_set_name(&my_kset.kobj, "my_kset"); ret = kset_register(&my_kset);A null pointer dereference exception is occurred:[ 4453.568337] Unable to handle kernel NULL pointer dereference at \virtual address 0000000000000028... ...[ 4453.810361] Call trace:[ 4453.813062] kobject_get_ownership+0xc/0x34[ 4453.817493] kobject_add_internal+0x98/0x274[ 4453.822005] kset_register+0x5c/0xb4[ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset]... ...Because I didn't initialize my_kset.kobj.ktype.According to the description in Documentation/core-api/kobject.rst: - A ktype is the type of object that embeds a kobject. Every structure that embeds a kobject needs a corresponding ktype.So add sanity check to make sure kset->kobj.ktype is not NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53482 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu: Fix error unwind in iommu_group_alloc()If either iommu_group_grate_file() fails then theiommu_group is leaked.Destroy it on these error paths.Found by kselftest/iommu/iommufd_fail_nth

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53489 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.syzkaller reported [0] memory leaks of an UDP socket and ZEROCOPYskbs. We can reproduce the problem with these sequences: sk = socket(AF_INET, SOCK_DGRAM, 0) sk.setsockopt(SOL_SOCKET, SO_TIMESTAMPING, SOF_TIMESTAMPING_TX_SOFTWARE) sk.setsockopt(SOL_SOCKET, SO_ZEROCOPY, 1) sk.sendto(b'', MSG_ZEROCOPY, ('127.0.0.1', 53)) sk.close()sendmsg() calls msg_zerocopy_alloc(), which allocates a skb, setsskb->cb->ubuf.refcnt to 1, and calls sock_hold(). Here, structubuf_info_msgzc indirectly holds a refcnt of the socket. When theskb is sent, __skb_tstamp_tx() clones it and puts the clone intothe socket's error queue with the TX timestamp.When the original skb is received locally, skb_copy_ubufs() callsskb_unclone(), and pskb_expand_head() increments skb->cb->ubuf.refcnt.This additional count is decremented while freeing the skb, but structubuf_info_msgzc still has a refcnt, so __msg_zerocopy_callback() isnot called.The last refcnt is not released unless we retrieve the TX timestampedskb by recvmsg(). Since we clear the error queue in inet_sock_destruct()after the socket's refcnt reaches 0, there is a circular dependency.If we close() the socket holding such skbs, we never call sock_put()and leak the count, sk, and skb.TCP has the same problem, and commit e0c8bccd40fc ("net: stream:purge sk_error_queue in sk_stream_kill_queues()") tried to fix itby calling skb_queue_purge() during close(). However, there is asmall chance that skb queued in a qdisc or device could be putinto the error queue after the skb_queue_purge() call.In __skb_tstamp_tx(), the cloned skb should not have a referenceto the ubuf to remove the circular dependency, but skb_clone() doesnot call skb_copy_ubufs() for zerocopy skb. So, we need to callskb_orphan_frags_rx() for the cloned skb to call skb_copy_ubufs().[0]:BUG: memory leakunreferenced object 0xffff88800c6d2d00 (size 1152): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 cd af e8 81 00 00 00 00 ................ 02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<0000000055636812>] sk_prot_alloc+0x64/0x2a0 net/core/sock.c:2024 [<0000000054d77b7a>] sk_alloc+0x3b/0x800 net/core/sock.c:2083 [<0000000066f3c7e0>] inet_create net/ipv4/af_inet.c:319 [inline] [<0000000066f3c7e0>] inet_create+0x31e/0xe40 net/ipv4/af_inet.c:245 [<000000009b83af97>] __sock_create+0x2ab/0x550 net/socket.c:1515 [<00000000b9b11231>] sock_create net/socket.c:1566 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1603 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1588 [inline] [<00000000b9b11231>] __sys_socket+0x138/0x250 net/socket.c:1636 [<000000004fb45142>] __do_sys_socket net/socket.c:1649 [inline] [<000000004fb45142>] __se_sys_socket net/socket.c:1647 [inline] [<000000004fb45142>] __x64_sys_socket+0x73/0xb0 net/socket.c:1647 [<0000000066999e0e>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<0000000066999e0e>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 [<0000000017f238c1>] entry_SYSCALL_64_after_hwframe+0x63/0xcdBUG: memory leakunreferenced object 0xffff888017633a00 (size 240): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) 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 2d 6d 0c 80 88 ff ff .........-m..... backtrace: [<000000002b1c4368>] __alloc_skb+0x229/0x320 net/core/skbuff.c:497 [<00000000143579a6>] alloc_skb include/linux/skbuff.h:1265 [inline] [<00000000143579a6>] sock_omalloc+0xaa/0x190 net/core/sock.c:2596 [<00000000be626478>] msg_zerocopy_alloc net/core/skbuff.c:1294 [inline] [<00000000be626478>]---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53495 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: mvpp2_main: fix possible OOB write in mvpp2_ethtool_get_rxnfc()rules is allocated in ethtool_get_rxnfc and the size is determined byrule_cnt from user space. So rule_cnt needs to be check before usingrules to avoid OOB writing or NULL pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53501 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbindWhen unbinding pasid - a race condition exists vs outstanding page faults.To prevent this, the pasid_state object contains a refcount. * set to 1 on pasid bind * incremented on each ppr notification start * decremented on each ppr notification done * decremented on pasid unbindSince refcount_dec assumes that refcount will never reach 0: the current implementation causes the following to be invoked on pasid unbind: REFCOUNT_WARN("decrement hit 0; leaking memory")Fix this issue by changing refcount_dec to refcount_dec_and_testto explicitly handle refcount=1.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53545 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: unmap and remove csa_va properlyRoot PD BO should be reserved before unmap and removea bo_va from VM otherwise lockdep will complain.v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian)[14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu][14616.937096] Call Trace:[14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu][14616.937187] drm_file_free+0x1d6/0x300 [drm][14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm][14616.937220] drm_release+0x5e/0x100 [drm][14616.937234] __fput+0x9f/0x280[14616.937239] ____fput+0xe/0x20[14616.937241] task_work_run+0x61/0x90[14616.937246] exit_to_user_mode_prepare+0x215/0x220[14616.937251] syscall_exit_to_user_mode+0x2a/0x60[14616.937254] do_syscall_64+0x48/0x90[14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53546 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: DR, fix memory leak in mlx5dr_cmd_create_reformat_ctxwhen mlx5_cmd_exec failed in mlx5dr_cmd_create_reformat_ctx, the memorypointed by 'in' is not released, which will cause memory leak. Move memoryrelease after mlx5_cmd_exec.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53549 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: Rework long task execution when adding/deleting entriesWhen adding/deleting large number of elements in one step in ipset, it cantake a reasonable amount of time and can result in soft lockup errors. Thepatch 5f7b51bf09ba ("netfilter: ipset: Limit the maximal range ofconsecutive elements to add/delete") tried to fix it by limiting the maxelements to process at all. However it was not enough, it is still possiblethat we get hung tasks. Lowering the limit is not reasonable, so theapproach in this patch is as follows: rely on the method used at resizingsets and save the state when we reach a smaller internal batch limit,unlock/lock and proceed from the saved state. Thus we can avoid longcontinuous tasks and at the same time removed the limit to add/delete largenumber of elements in one step.The nfnl mutex is held during the whole operation which prevents one toissue other ipset commands in parallel.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53561 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: wwan: iosm: fix NULL pointer dereference when removing deviceIn suspend and resume cycle, the removal and rescan of device endsup in NULL pointer dereference.During driver initialization, if the ipc_imem_wwan_channel_init()fails to get the valid device capabilities it returns an error andfurther no resource (wwan struct) will be allocated. Now in thissituation if driver removal procedure is initiated it would resultin NULL pointer exception since unallocated wwan struct is dereferencedinside ipc_wwan_deinit().ipc_imem_run_state_worker() to handle the called functions return valueand to release the resource in failure case. It also reports the linkdown event in failure cases. The user space application can handle thisevent to do a device reset for restoring the device communication.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53562 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: fix vram leak on bind errorsMake sure to release the VRAM buffer also in a case a subcomponent failsto bind.Patchwork: https://patchwork.freedesktop.org/patch/525094/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53577 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, cpumap: Make sure kthread is running before map update returnsThe following warning was reported when running stress-mode enabledxdp_redirect_cpu with some RT threads: ------------[ cut here ]------------ WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135 CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events cpu_map_kthread_stop RIP: 0010:put_cpu_map_entry+0xda/0x220 ...... Call Trace: ? show_regs+0x65/0x70 ? __warn+0xa5/0x240 ...... ? put_cpu_map_entry+0xda/0x220 cpu_map_kthread_stop+0x41/0x60 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 The root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memoryleak in cpu_map_update_elem"). The kthread is stopped prematurely bykthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't callcpu_map_kthread_run() at all but XDP program has already queued someframes or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checksthe ptr_ring, it will find it was not emptied and report a warning.An alternative fix is to use __cpu_map_ring_cleanup() to drop thesepending frames or skbs when kthread_stop() returns -EINTR, but it mayconfuse the user, because these frames or skbs have been handledcorrectly by XDP program. So instead of dropping these frames or skbs,just make sure the per-cpu kthread is running before__cpu_map_entry_alloc() returns.After apply the fix, the error handle for kthread_stop() will beunnecessary because it will always return 0, so just remove it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53578 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume()Syzbot reported a bug as following:=====================================================BUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 __netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630 qrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdIt is because that skb->len requires at least sizeof(struct qrtr_ctrl_pkt)in qrtr_tx_resume(). And skb->len equals to size in qrtr_endpoint_post().But size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb->typeequals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbotscenario. This triggers the uninit variable access bug.Add size check when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX inqrtr_endpoint_post() to fix the bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53580 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: Gadget: core: Help prevent panic during UVC unconfigureAvichal Rakesh reported a kernel panic that occurred when the UVCgadget driver was removed from a gadget's configuration. The panicinvolves a somewhat complicated interaction between the kernel driverand a userspace component (as described in the Link tag below), butthe analysis did make one thing clear: The Gadget core shouldaccomodate gadget drivers calling usb_gadget_deactivate() as part oftheir unbind procedure.Currently this doesn't work. gadget_unbind_driver() callsdriver->unbind() while holding the udc->connect_lock mutex, andusb_gadget_deactivate() attempts to acquire that mutex, which willresult in a deadlock.The simple fix is for gadget_unbind_driver() to release the mutex wheninvoking the ->unbind() callback. There is no particular reason forit to be holding the mutex at that time, and the mutex isn't heldwhile the ->bind() callback is invoked. So we'll drop the mutexbefore performing the unbind callback and reacquire it afterward.We'll also add a couple of comments to usb_gadget_activate() andusb_gadget_deactivate(). Because they run in process context theymust not be called from a gadget driver's ->disconnect() callback,which (according to the kerneldoc for struct usb_gadget_driver ininclude/linux/usb/gadget.h) may run in interrupt context. This mayhelp prevent similar bugs from arising in the future.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53591 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix deadlock in tc route query codeCited commit causes ABBA deadlock[0] when peer flows are created whileholding the devcom rw semaphore. Due to peer flows offload implementationthe lock is taken much higher up the call chain and there is no obvious wayto easily fix the deadlock. Instead, since tc route query code needs thepeer eswitch structure only to perform a lookup in xarray and doesn'tperform any sleeping operations with it, refactor the code for locklessexecution in following ways:- RCUify the devcom 'data' pointer. When resetting the pointersynchronously wait for RCU grace period before returning. This is finesince devcom is currently only used for synchronization ofpairing/unpairing of eswitches which is rare and already expensive as-is.- Wrap all usages of 'paired' boolean in {READ|WRITE}_ONCE(). The flag hasalready been used in some unlocked contexts without properannotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn'tan issue since all relevant code paths checked it again after obtaining thedevcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as"best effort" check to return NULL when devcom is being unpaired. Note thatwhile RCU read lock doesn't prevent the unpaired flag from being changedconcurrently it still guarantees that reader can continue to use 'data'.- Refactor mlx5e_tc_query_route_vport() function to use newmlx5_devcom_get_peer_data_rcu() API which fixes the deadlock.[0]:[ 164.599612] ======================================================[ 164.600142] WARNING: possible circular locking dependency detected[ 164.600667] 6.3.0-rc3+ #1 Not tainted[ 164.601021] ------------------------------------------------------[ 164.601557] handler1/3456 is trying to acquire lock:[ 164.601998] ffff88811f1714b0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core][ 164.603078] but task is already holding lock:[ 164.603617] ffff88810137fc98 (&comp->sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core][ 164.604459] which lock already depends on the new lock.[ 164.605190] the existing dependency chain (in reverse order) is:[ 164.605848] -> #1 (&comp->sem){++++}-{3:3}:[ 164.606380] down_read+0x39/0x50[ 164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core][ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core][ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core][ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core][ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core][ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core][ 164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core][ 164.610741] tc_setup_cb_add+0xd4/0x200[ 164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower][ 164.611661] fl_change+0xc95/0x18a0 [cls_flower][ 164.612116] tc_new_tfilter+0x3fc/0xd20[ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0[ 164.612936] netlink_rcv_skb+0x54/0x100[ 164.613339] netlink_unicast+0x190/0x250[ 164.613746] netlink_sendmsg+0x245/0x4a0[ 164.614150] sock_sendmsg+0x38/0x60[ 164.614522] ____sys_sendmsg+0x1d0/0x1e0[ 164.614934] ___sys_sendmsg+0x80/0xc0[ 164.615320] __sys_sendmsg+0x51/0x90[ 164.615701] do_syscall_64+0x3d/0x90[ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0[ 164.616568] -> #0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}:[ 164.617210] __lock_acquire+0x159e/0x26e0[ 164.617638] lock_acquire+0xc2/0x2a0[ 164.618018] __mutex_lock+0x92/0xcd0[ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core][ 164.618943] post_process_attr+0x153/0x2d0 [---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53596 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drivers: base: Free devm resources when unregistering a deviceIn the current code, devres_release_all() only gets called if the devicehas a bus and has been probed.This leads to issues when using bus-less or driver-less devices wherethe device might never get freed if a managed resource holds a referenceto the device. This is happening in the DRM framework for example.We should thus call devres_release_all() in the device_del() function tomake sure that the device-managed actions are properly executed when thedevice is unregistered, even if it has neither a bus nor a driver.This is effectively the same change than commit 2f8d16a996da ("devres:release resources on device_del()") that got reverted by commita525a3ddeaca ("driver core: free devres in device_release") overmemory leaks concerns.This patch effectively combines the two commits mentioned above torelease the resources both on device_del() and device_release() and getthe best of both worlds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53598 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Range check CHDBOFF and ERDBOFFIf the value read from the CHDBOFF and ERDBOFF registers is outside therange of the MHI register space then an invalid address might be computedwhich later causes a kernel panic. Range check the read value to preventa crash due to bad data from the device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53600 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tunnels: fix kasan splat when generating ipv4 pmtu errorIf we try to emit an icmp error in response to a nonliner skb, we getBUG: KASAN: slab-out-of-bounds in ip_compute_csum+0x134/0x220Read of size 4 at addr ffff88811c50db00 by task iperf3/1691CPU: 2 PID: 1691 Comm: iperf3 Not tainted 6.5.0-rc3+ #309[..] kasan_report+0x105/0x140 ip_compute_csum+0x134/0x220 iptunnel_pmtud_build_icmp+0x554/0x1020 skb_tunnel_check_pmtu+0x513/0xb80 vxlan_xmit_one+0x139e/0x2ef0 vxlan_xmit+0x1867/0x2760 dev_hard_start_xmit+0x1ee/0x4f0 br_dev_queue_push_xmit+0x4d1/0x660 [..]ip_compute_csum() cannot deal with nonlinear skbs, so avoid it.After this change, splat is gone and iperf3 is no longer stuck.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53601 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: do not assume skb mac_header is setDrivers must not assume in their ndo_start_xmit() thatskbs have their mac_header set. skb->data is all what is needed.bonding seems to be one of the last offender as caught by syzbot:WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 skb_mac_offset include/linux/skbuff.h:2913 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 __bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470Modules linked in:CPU: 1 PID: 12155 Comm: syz-executor.3 Not tainted 6.1.30-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023RIP: 0010:skb_mac_header include/linux/skbuff.h:2907 [inline]RIP: 0010:skb_mac_offset include/linux/skbuff.h:2913 [inline]RIP: 0010:bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]RIP: 0010:bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]RIP: 0010:bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]RIP: 0010:__bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]RIP: 0010:bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470Code: 8b 7c 24 30 e8 76 dd 1a 01 48 85 c0 74 0d 48 89 c3 e8 29 67 2e fe e9 15 ef ff ff e8 1f 67 2e fe e9 10 ef ff ff e8 15 67 2e fe <0f> 0b e9 45 f8 ff ff e8 09 67 2e fe e9 dc fa ff ff e8 ff 66 2e feRSP: 0018:ffffc90002fff6e0 EFLAGS: 00010283RAX: ffffffff835874db RBX: 000000000000ffff RCX: 0000000000040000RDX: ffffc90004dcf000 RSI: 00000000000000b5 RDI: 00000000000000b6RBP: ffffc90002fff8b8 R08: ffffffff83586d16 R09: ffffffff83586584R10: 0000000000000007 R11: ffff8881599fc780 R12: ffff88811b6a7b7eR13: 1ffff110236d4f6f R14: ffff88811b6a7ac0 R15: 1ffff110236d4f76FS: 00007f2e9eb47700(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b2e421000 CR3: 000000010e6d4000 CR4: 00000000003526e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:[] netdev_start_xmit include/linux/netdevice.h:4925 [inline][] __dev_direct_xmit+0x4ef/0x850 net/core/dev.c:4380[] dev_direct_xmit include/linux/netdevice.h:3043 [inline][] packet_direct_xmit+0x18b/0x300 net/packet/af_packet.c:284[] packet_snd net/packet/af_packet.c:3112 [inline][] packet_sendmsg+0x4a22/0x64d0 net/packet/af_packet.c:3143[] sock_sendmsg_nosec net/socket.c:716 [inline][] sock_sendmsg net/socket.c:736 [inline][] __sys_sendto+0x472/0x5f0 net/socket.c:2139[] __do_sys_sendto net/socket.c:2151 [inline][] __se_sys_sendto net/socket.c:2147 [inline][] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147[] do_syscall_x64 arch/x86/entry/common.c:50 [inline][] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80[] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53610 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip: Fix refcount leak in platform_irqchip_probeof_irq_find_parent() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53613 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dax: Fix dax_mapping_release() use after freeA CONFIG_DEBUG_KOBJECT_RELEASE test of removing a device-dax regionprovider (like modprobe -r dax_hmem) yields: kobject: 'mapping0' (ffff93eb460e8800): kobject_release, parent 0000000000000000 (delayed 2000) [..] DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 23 PID: 282 at kernel/locking/lockdep.c:232 __lock_acquire+0x9fc/0x2260 [..] RIP: 0010:__lock_acquire+0x9fc/0x2260 [..] Call Trace: [..] lock_acquire+0xd4/0x2c0 ? ida_free+0x62/0x130 _raw_spin_lock_irqsave+0x47/0x70 ? ida_free+0x62/0x130 ida_free+0x62/0x130 dax_mapping_release+0x1f/0x30 device_release+0x36/0x90 kobject_delayed_cleanup+0x46/0x150Due to attempting ida_free() on an ida object that has already beenfreed. Devices typically only hold a reference on their parent whileregistered. If a child needs a parent object to complete its release itneeds to hold a reference that it drops from its release callback.Arrange for a dax_mapping to pin its parent dev_dax instance untildax_mapping_release().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53618 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reject invalid reloc tree root keys with stack dump[BUG]Syzbot reported a crash that an ASSERT() got triggered insideprepare_to_merge().That ASSERT() makes sure the reloc tree is properly pointed back by itssubvolume tree.[CAUSE]After more debugging output, it turns out we had an invalid reloc tree: BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM,QUOTA_TREE_OBJECTID), meaning it's a reloc tree for quota tree.But reloc trees can only exist for subvolumes, as for non-subvolumetrees, we just COW the involved tree block, no need to create a reloctree since those tree blocks won't be shared with other trees.Only subvolumes tree can share tree blocks with other trees (thus theyhave BTRFS_ROOT_SHAREABLE flag).Thus this new debug output proves my previous assumption that corruptedon-disk data can trigger that ASSERT().[FIX]Besides the dedicated fix and the graceful exit, also let tree-checker tocheck such root keys, to make sure reloc trees can only exist for subvolumes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53620 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md: fix soft lockup in status_resyncstatus_resync() will calculate 'curr_resync - recovery_active' to showuser a progress bar like following:[============>........] resync = 61.4%'curr_resync' and 'recovery_active' is updated in md_do_sync(), andstatus_resync() can read them concurrently, hence it's possible that'curr_resync - recovery_active' can overflow to a huge number. In thiscase status_resync() will be stuck in the loop to print a large amountof '=', which will end up soft lockup.Fix the problem by setting 'resync' to MD_RESYNC_ACTIVE in this case,this way resync in progress will be reported to user.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53627 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Grab sas_dev lock when traversing the members of sas_dev.listWhen freeing slots in function slot_complete_v3_hw(), it is possible thatsas_dev.list is being traversed elsewhere, and it may trigger a NULLpointer exception, such as follows:==>cq thread ==>scsi_eh_6 ==>scsi_error_handler() ==>sas_eh_handle_sas_errors() ==>sas_scsi_find_task() ==>lldd_abort_task()==>slot_complete_v3_hw() ==>hisi_sas_abort_task() ==>hisi_sas_slot_task_free() ==>dereg_device_v3_hw() ==>list_del_init() ==>list_for_each_entry_safe()[ 7165.434918] sas: Enter sas_scsi_recover_host busy: 32 failed: 32[ 7165.434926] sas: trying to find task 0x00000000769b5ba5[ 7165.434927] sas: sas_scsi_find_task: aborting task 0x00000000769b5ba5[ 7165.434940] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted[ 7165.434964] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored[ 7165.434965] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000e2a1cf01) ignored[ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000[ 7165.434972] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000022d52d93) ignored[ 7165.434975] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000066a7516c) ignored[ 7165.434976] Mem abort info:[ 7165.434982] ESR = 0x96000004[ 7165.434991] Exception class = DABT (current EL), IL = 32 bits[ 7165.434992] SET = 0, FnV = 0[ 7165.434993] EA = 0, S1PTW = 0[ 7165.434994] Data abort info:[ 7165.434994] ISV = 0, ISS = 0x00000004[ 7165.434995] CM = 0, WnR = 0[ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2[ 7165.434998] [0000000000000000] pgd=0000000000000000[ 7165.435003] Internal error: Oops: 96000004 [#1] SMP[ 7165.439863] Process scsi_eh_6 (pid: 4109, stack limit = 0x00000000c43818d5)[ 7165.468862] pstate: 00c00009 (nzcv daif +PAN +UAO)[ 7165.473637] pc : dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw][ 7165.479443] lr : dereg_device_v3_hw+0x2c/0xa8 [hisi_sas_v3_hw][ 7165.485247] sp : ffff00001d623bc0[ 7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508[ 7165.493835] x27: ffff80278ed50af0 x26: ffffa027dd31e0a8[ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8[ 7165.504411] x23: ffffa027c45b0d60 x22: ffff80278ec07c00[ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8[ 7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff[ 7165.520276] x17: 0000000000000000 x16: 0000000000000000[ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8[ 7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067[ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0[ 7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00[ 7165.546718] x7 : ffffa027d6329600 x6 : ffff7e809f58ca00[ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e[ 7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000[ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e[ 7165.567872] Call trace:[ 7165.570309] dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw][ 7165.575775] hisi_sas_abort_task+0x248/0x358 [hisi_sas_main][ 7165.581415] sas_eh_handle_sas_errors+0x258/0x8e0 [libsas][ 7165.586876] sas_scsi_recover_host+0x134/0x458 [libsas][ 7165.592082] scsi_error_handler+0xb4/0x488[ 7165.596163] kthread+0x134/0x138[ 7165.599380] ret_from_fork+0x10/0x18[ 7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021)[ 7165.609004] kernel fault(0x1) notification starting on CPU 75[ 7165.700728] ---[ end trace fc042cbbea224efc ]---[ 7165.705326] Kernel panic - not syncing: Fatal exceptionTo fix the issue, grab sas_dev lock when traversing the members ofsas_dev.list in dereg_device_v3_hw() and hisi_sas_release_tasks() to avoidconcurrency of adding and deleting member. When ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53647 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Don't dereference ACPI root object handleSince the commit referenced in the Fixes: tag below the VMBus client driveris walking the ACPI namespace up from the VMBus ACPI device to the ACPInamespace root object trying to find Hyper-V MMIO ranges.However, if it is not able to find them it ends trying to walk resources ofthe ACPI namespace root object itself.This object has all-ones handle, which causes a NULL pointer dereferencein the ACPI code (from dereferencing this pointer with an offset).This in turn causes an oops on boot with VMBus host implementations that donot provide Hyper-V MMIO ranges in their VMBus ACPI device or itsancestors.The QEMU VMBus implementation is an example of such implementation.I guess providing these ranges is optional, since all tested Windowsversions seem to be able to use VMBus devices without them.Fix this by explicitly terminating the lookup at the ACPI namespace rootobject.Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interfaceby default - they only do so if the KVM PV interface is missing ordisabled.Example stack trace of such oops:[ 3.710827] ? __die+0x1f/0x60[ 3.715030] ? page_fault_oops+0x159/0x460[ 3.716008] ? exc_page_fault+0x73/0x170[ 3.716959] ? asm_exc_page_fault+0x22/0x30[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0[ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0[ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200[ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0[ 3.723559] ? down_timeout+0x3a/0x60[ 3.724455] ? acpi_ns_get_node+0x3a/0x60[ 3.725412] acpi_ns_get_node+0x3a/0x60[ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0[ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0[ 3.728400] acpi_rs_get_method_data+0x2b/0x70[ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus][ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus][ 3.732411] acpi_walk_resources+0x78/0xd0[ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus][ 3.734802] platform_probe+0x3d/0x90[ 3.735684] really_probe+0x19b/0x400[ 3.736570] ? __device_attach_driver+0x100/0x100[ 3.737697] __driver_probe_device+0x78/0x160[ 3.738746] driver_probe_device+0x1f/0x90[ 3.739743] __driver_attach+0xc2/0x1b0[ 3.740671] bus_for_each_dev+0x70/0xc0[ 3.741601] bus_add_driver+0x10e/0x210[ 3.742527] driver_register+0x55/0xf0[ 3.744412] ? 0xffffffffc039a000[ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53657 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Don't tx before switchdev is fully configuredThere is possibility that ice_eswitch_port_start_xmit might becalled while some resources are still not allocated which mightcause NULL pointer dereference. Fix this by checking if switchdevconfiguration was finished.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53672 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: output extra debug info if we failed to find an inline backref[BUG]Syzbot reported several warning triggered insidelookup_inline_extent_backref().[CAUSE]As usual, the reproducer doesn't reliably trigger locally here, but atleast we know the WARN_ON() is triggered when an inline backref can notbe found, and it can only be triggered when @insert is true. (I.e.inserting a new inline backref, which means the backref should alreadyexist)[ENHANCEMENT]After the WARN_ON(), dump all the parameters and the extent treeleaf to help debug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53684 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Zero padding when dumping algos and encapWhen copying data to user-space we should ensure that only validdata is copied over. Padding in structures may be filled withrandom (possibly sensitve) data and should never be given directlyto user-space.This patch fixes the copying of xfrm algorithms and the encaptemplate in xfrm_user so that padding is zeroed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53727 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: fq_pie: avoid stalls in fq_pie_timer()When setting a high number of flows (limit being 65536),fq_pie_timer() is currently using too much time as syzbot reported.Add logic to yield the cpu every 2048 flows (less than 150 usecon debug kernels).It should also help by not blocking qdisc fast paths for too long.Worst case (65536 flows) would need 31 jiffies for a complete scan.Relevant extract from syzbot report:rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 0-.... } 2663 jiffies s: 873 root: 0x1/.rcu: blocking rcu_node structures (internal RCU debug):Sending NMI from CPU 1 to CPUs 0:NMI backtrace for cpu 0CPU: 0 PID: 5177 Comm: syz-executor273 Not tainted 6.5.0-syzkaller-00453-g727dbda16b83 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline]RIP: 0010:write_comp_data+0x21/0x90 kernel/kcov.c:236Code: 2e 0f 1f 84 00 00 00 00 00 65 8b 05 01 b2 7d 7e 49 89 f1 89 c6 49 89 d2 81 e6 00 01 00 00 49 89 f8 65 48 8b 14 25 80 b9 03 00 00 01 ff 00 74 0e 85 f6 74 59 8b 82 04 16 00 00 85 c0 74 4f 8bRSP: 0018:ffffc90000007bb8 EFLAGS: 00000206RAX: 0000000000000101 RBX: ffffc9000dc0d140 RCX: ffffffff885893b0RDX: ffff88807c075940 RSI: 0000000000000100 RDI: 0000000000000001RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000dc0d178R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 0000555555d54380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f6b442f6130 CR3: 000000006fe1c000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: pie_calculate_probability+0x480/0x850 net/sched/sch_pie.c:415 fq_pie_timer+0x1da/0x4f0 net/sched/sch_fq_pie.c:387 call_timer_fn+0x1a0/0x580 kernel/time/timer.c:1700

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53745 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:um: vector: Fix memory leak in vector_configIf the return value of the uml_parse_vector_ifspec function is NULL,we should call kfree(params) to prevent memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53748 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: Fix potential array out-of-bounds in decoder queue_setupvariable *nplanes is provided by user via system call argument. Thepossible value of q_data->fmt->num_planes is 1-3, while the valueof *nplanes can be 1-8. The array access by index i can cause arrayout-of-bounds.Fix this bug by checking *nplanes against the array size.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53753 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: fix mapping to non-allocated address[Why]There is an issue mapping non-allocated location of memory.It would allocate gpio registers from an array out of bounds.[How]Patch correct numbers of bounds for using.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53757 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/irq-mvebu-gicp: Fix refcount leak in mvebu_gicp_probeof_irq_find_parent() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53769 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virt/coco/sev-guest: Double-buffer messagesThe encryption algorithms read and write directly to shared unencryptedmemory, which may leak information as well as permit the host to tamperwith the message integrity. Instead, copy whole messages in or out asneeded before doing any computation on them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53785 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7921: don't assume adequate headroom for SDIO headersmt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() andmt7921_skb_add_usb_sdio_hdr(), both of which blindly assume thatadequate headroom will be available in the passed skb. This assumptiontypically is satisfied when the skb was allocated in the net core fortransmission via the mt7921 netdev (although even that is only anoptimization and is not strictly guaranteed), but the assumption issometimes not satisfied when the skb originated in the receive path ofanother netdev and was passed through to the mt7921, such as by thebridge layer. Blindly prepending bytes to an skb is always wrong.This commit introduces a call to skb_cow_head() before the call tomt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() toensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE bytes can bepushed onto the skb.Without this fix, I can trivially cause kernel panics by bridging anMT7921AU-based USB 802.11ax interface with an Ethernet interface on anIntel Atom-based x86 system using its onboard RTL8169 PCI Ethernetadapter and also on an ARM-based Raspberry Pi 1 using its onboardSMSC9512 USB Ethernet adapter. Note that the panics do not occur inevery system configuration, as they occur only if the receiving netdevleaves less headroom in its received skbs than the mt7921 needs for itsSDIO headers.Here is an example stack trace of this panic on Raspberry Pi OS Lite2023-02-21 running kernel 6.1.24+ [1]: skb_panic from skb_push+0x44/0x48 skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common] mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb] mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76] __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76] mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76] mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common] mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76] __mt76_worker_fn [mt76] from kthread+0xbc/0xe0 kthread from ret_from_fork+0x14/0x34After this fix, bridging the mt7921 interface works fine on both of mypreviously problematic systems.[1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53798 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: Fix uninitialized number of lanesIt is not possible to set the number of lanes when setting link modesusing the legacy IOCTL ethtool interface. Since 'structethtool_link_ksettings' is not initialized in this path, drivers receivean uninitialized number of lanes in 'structethtool_link_ksettings::lanes'.When this information is later queried from drivers, it results in theethtool code making decisions based on uninitialized memory, leading tothe following KMSAN splat [1]. In practice, this most likely onlyhappens with the tun driver that simply returns whatever it got in theset operation.As far as I can tell, this uninitialized memory is not leaked to userspace thanks to the 'ethtool_ops->cap_link_lanes_supported' check inlinkmodes_prepare_data().Fix by initializing the structure in the IOCTL path. Did not find anymore call sites that pass an uninitialized structure when calling'ethtool_ops::set_link_ksettings()'.[1]BUG: KMSAN: uninit-value in ethnl_update_linkmodes net/ethtool/linkmodes.c:273 [inline]BUG: KMSAN: uninit-value in ethnl_set_linkmodes+0x190b/0x19d0 net/ethtool/linkmodes.c:333 ethnl_update_linkmodes net/ethtool/linkmodes.c:273 [inline] ethnl_set_linkmodes+0x190b/0x19d0 net/ethtool/linkmodes.c:333 ethnl_default_set_doit+0x88d/0xde0 net/ethtool/netlink.c:640 genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline] genl_rcv_msg+0x141a/0x14c0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x3f8/0x750 net/netlink/af_netlink.c:2577 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0xf41/0x1270 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x127d/0x1430 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555 __sys_sendmsg net/socket.c:2584 [inline] __do_sys_sendmsg net/socket.c:2593 [inline] __se_sys_sendmsg net/socket.c:2591 [inline] __x64_sys_sendmsg+0x36b/0x540 net/socket.c:2591 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was stored to memory at: tun_get_link_ksettings+0x37/0x60 drivers/net/tun.c:3544 __ethtool_get_link_ksettings+0x17b/0x260 net/ethtool/ioctl.c:441 ethnl_set_linkmodes+0xee/0x19d0 net/ethtool/linkmodes.c:327 ethnl_default_set_doit+0x88d/0xde0 net/ethtool/netlink.c:640 genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline] genl_rcv_msg+0x141a/0x14c0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x3f8/0x750 net/netlink/af_netlink.c:2577 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0xf41/0x1270 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x127d/0x1430 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555 __sys_sendmsg net/socket.c:2584 [inline] __do_sys_sendmsg net/socket.c:2593 [inline] __se_sys_sendmsg net/socket.c:2591 [inline] __x64_sys_sendmsg+0x36b/0x540 net/socket.c:2591 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was stored to memory at: tun_set_link_ksettings+0x37/0x60 drivers/net/tun.c:3553 ethtool_set_link_ksettings+0x600/0x690 net/ethtool/ioctl.c:609 __dev_ethtool net/ethtool/ioctl.c:3024 [inline] dev_ethtool+0x1db9/0x2a70 net/ethtool/ioctl.c:3078 dev_ioctl+0xb07/0x1270 net/core/dev_ioctl.c:524 sock_do_ioctl+0x295/0x540 net/socket.c:1213 sock_i---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53799 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: api - Use work queue in crypto_destroy_instanceThe function crypto_drop_spawn expects to be called in processcontext. However, when an instance is unregistered while it stillhas active users, the last user may cause the instance to be freedin atomic context.Fix this by delaying the freeing to a work queue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53801 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/sprd: Release dma buffer to avoid memory leakWhen attaching to a domain, the driver would alloc a DMA buffer whichis used to store address mapping table, and it need to be releasedwhen the IOMMU domain is freed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53807 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: clocking-wizard: Fix Oops in clk_wzrd_register_divider()Smatch detected this potential error pointer dereferenceclk_wzrd_register_divider(). If devm_clk_hw_register() fails thenit sets "hw" to an error pointer and then dereferences it on thenext line. Return the error directly instead.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53810 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: release crypto keyslot before reporting I/O completeOnce all I/O using a blk_crypto_key has completed, filesystems can callblk_crypto_evict_key(). However, the block layer currently doesn't callblk_crypto_put_keyslot() until the request is being freed, which happensafter upper layers have been told (via bio_endio()) the I/O hascompleted. This causes a race condition where blk_crypto_evict_key()can see 'slot_refs != 0' without there being an actual bug.This makes __blk_crypto_evict_key() hit the'WARN_ON_ONCE(atomic_read(&slot->slot_refs) != 0)' and return withoutdoing anything, eventually causing a use-after-free inblk_crypto_reprogram_all_keys(). (This is a very rare bug and has onlybeen seen when per-file keys are being used with fscrypt.)There are two options to fix this: either release the keyslot beforebio_endio() is called on the request's last bio, or make__blk_crypto_evict_key() ignore slot_refs. Let's go with the firstsolution, since it preserves the ability to report bugs (viaWARN_ON_ONCE) where a key is evicted while still in-use.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53815 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:posix-timers: Prevent RT livelock in itimer_delete()itimer_delete() has a retry loop when the timer is concurrently expired. Onnon-RT kernels this just spin-waits until the timer callback has completed,except for posix CPU timers which have HAVE_POSIX_CPU_TIMERS_TASK_WORKenabled.In that case and on RT kernels the existing task could live lock whenpreempting the task which does the timer delivery.Replace spin_unlock() with an invocation of timer_wait_running() to handleit the same way as the other retry loops in the posix timer code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53817 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()During NVMeTCP Authentication a controller can trigger a kerneloops by specifying the 8192 bit Diffie Hellman group and passinga correctly sized, but zeroed Diffie Hellamn value.mpi_cmp_ui() was detecting this if the second parameter was 0,but 1 is passed from dh_is_pubkey_valid(). This causes the nullpointer u->d to be dereferenced towards the end of mpi_cmp_ui()

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53822 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: Ignore frags from uninitialized peer in dp.When max virtual ap interfaces are configured in all the bands withACS and hostapd restart is done every 60s, a crash is observed atrandom times.In this certain scenario, a fragmented packet is received forself peer, for which rx_tid and rx_frags are not initialized indatapath. While handling this fragment, crash is observed as therx_frag list is uninitialised and when we walk inath11k_dp_rx_h_sort_frags, skb null leads to exception.To address this, before processing received fragments we checkdp_setup_done flag is set to ensure that peer has completed itsdp peer setup for fragment queue, else ignore processing thefragments.Call trace: ath11k_dp_process_rx_err+0x550/0x1084 [ath11k] ath11k_dp_service_srng+0x70/0x370 [ath11k] 0xffffffc009693a04 __napi_poll+0x30/0xa4 net_rx_action+0x118/0x270 __do_softirq+0x10c/0x244 irq_exit+0x64/0xb4 __handle_domain_irq+0x88/0xac gic_handle_irq+0x74/0xbc el1_irq+0xf0/0x1c0 arch_cpu_idle+0x10/0x18 do_idle+0x104/0x248 cpu_startup_entry+0x20/0x64 rest_init+0xd0/0xdc arch_call_rest_init+0xc/0x14 start_kernel+0x480/0x4b8 Code: f9400281 f94066a2 91405021 b94a0023 (f9406401)Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53824 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: annotate lockless accesses to nlk->max_recvmsg_lensyzbot reported a data-race in data-race in netlink_recvmsg() [1]Indeed, netlink_recvmsg() can be run concurrently,and netlink_dump() also needs protection.[1]BUG: KCSAN: data-race in netlink_recvmsg / netlink_recvmsgread to 0xffff888141840b38 of 8 bytes by task 23057 on cpu 0:netlink_recvmsg+0xea/0x730 net/netlink/af_netlink.c:1988sock_recvmsg_nosec net/socket.c:1017 [inline]sock_recvmsg net/socket.c:1038 [inline]__sys_recvfrom+0x1ee/0x2e0 net/socket.c:2194__do_sys_recvfrom net/socket.c:2212 [inline]__se_sys_recvfrom net/socket.c:2208 [inline]__x64_sys_recvfrom+0x78/0x90 net/socket.c:2208do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdwrite to 0xffff888141840b38 of 8 bytes by task 23037 on cpu 1:netlink_recvmsg+0x114/0x730 net/netlink/af_netlink.c:1989sock_recvmsg_nosec net/socket.c:1017 [inline]sock_recvmsg net/socket.c:1038 [inline]____sys_recvmsg+0x156/0x310 net/socket.c:2720___sys_recvmsg net/socket.c:2762 [inline]do_recvmmsg+0x2e5/0x710 net/socket.c:2856__sys_recvmmsg net/socket.c:2935 [inline]__do_sys_recvmmsg net/socket.c:2958 [inline]__se_sys_recvmmsg net/socket.c:2951 [inline]__x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x0000000000000000 -> 0x0000000000001000Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 23037 Comm: syz-executor.2 Not tainted 6.3.0-rc4-syzkaller-00195-g5a57b48fdfcb #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53825 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kcm: Fix error handling for SOCK_DGRAM in kcm_sendmsg().syzkaller found a memory leak in kcm_sendmsg(), and commit c821a88bd720("kcm: Fix memory leak in error path of kcm_sendmsg()") suppressed it byupdating kcm_tx_msg(head)->last_skb if partial data is copied so that thefollowing sendmsg() will resume from the skb.However, we cannot know how many bytes were copied when we get the error.Thus, we could mess up the MSG_MORE queue.When kcm_sendmsg() fails for SOCK_DGRAM, we should purge the queue as wedo so for UDP by udp_flush_pending_frames().Even without this change, when the error occurred, the following sendmsg()resumed from a wrong skb and the queue was messed up. However, we haveyet to get such a report, and only syzkaller stumbled on it. So, thiscan be changed safely.Note this does not change SOCK_SEQPACKET behaviour.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53831 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: read sk->sk_family once in sk_mc_loop()syzbot is playing with IPV6_ADDRFORM quite a lot these days,and managed to hit the WARN_ON_ONCE(1) in sk_mc_loop()We have many more similar issues to fix.WARNING: CPU: 1 PID: 1593 at net/core/sock.c:782 sk_mc_loop+0x165/0x260Modules linked in:CPU: 1 PID: 1593 Comm: kworker/1:3 Not tainted 6.1.40-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023Workqueue: events_power_efficient gc_workerRIP: 0010:sk_mc_loop+0x165/0x260 net/core/sock.c:782Code: 34 1b fd 49 81 c7 18 05 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 20 00 74 08 4c 89 ff e8 25 36 6d fd 4d 8b 37 eb 13 e8 db 33 1b fd <0f> 0b b3 01 eb 34 e8 d0 33 1b fd 45 31 f6 49 83 c6 38 4c 89 f0 48RSP: 0018:ffffc90000388530 EFLAGS: 00010246RAX: ffffffff846d9b55 RBX: 0000000000000011 RCX: ffff88814f884980RDX: 0000000000000102 RSI: ffffffff87ae5160 RDI: 0000000000000011RBP: ffffc90000388550 R08: 0000000000000003 R09: ffffffff846d9a65R10: 0000000000000002 R11: ffff88814f884980 R12: dffffc0000000000R13: ffff88810dbee000 R14: 0000000000000010 R15: ffff888150084000FS: 0000000000000000(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000180 CR3: 000000014ee5b000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:[] ip6_finish_output2+0x33f/0x1ae0 net/ipv6/ip6_output.c:83[] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline][] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211[] NF_HOOK_COND include/linux/netfilter.h:298 [inline][] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232[] dst_output include/net/dst.h:444 [inline][] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161[] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline][] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline][] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline][] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677[] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229[] netdev_start_xmit include/linux/netdevice.h:4925 [inline][] xmit_one net/core/dev.c:3644 [inline][] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660[] sch_direct_xmit+0x2a0/0x9c0 net/sched/sch_generic.c:342[] qdisc_restart net/sched/sch_generic.c:407 [inline][] __qdisc_run+0xb13/0x1e70 net/sched/sch_generic.c:415[] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125[] net_tx_action+0x7ac/0x940 net/core/dev.c:5247[] __do_softirq+0x2bd/0x9bd kernel/softirq.c:599[] invoke_softirq kernel/softirq.c:430 [inline][] __irq_exit_rcu+0xc8/0x170 kernel/softirq.c:683[] irq_exit_rcu+0x9/0x20 kernel/softirq.c:695

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53836 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix skb refcnt race after locking changesThere is a race where skb's from the sk_psock_backlog can be referencedafter userspace side has already skb_consumed() the sk_buff and its refcntdropped to zer0 causing use after free.The flow is the following: while ((skb = skb_peek(&psock->ingress_skb)) sk_psock_handle_Skb(psock, skb, ..., ingress) if (!ingress) ... sk_psock_skb_ingress sk_psock_skb_ingress_enqueue(skb) msg->skb = skb sk_psock_queue_msg(psock, msg) skb_dequeue(&psock->ingress_skb)The sk_psock_queue_msg() puts the msg on the ingress_msg queue. This iswhat the application reads when recvmsg() is called. An application canread this anytime after the msg is placed on the queue. The recvmsg hookwill also read msg->skb and then after user space reads the msg will callconsume_skb(skb) on it effectively free'ing it.But, the race is in above where backlog queue still has a reference tothe skb and calls skb_dequeue(). If the skb_dequeue happens after theuser reads and free's the skb we have a use after free.The !ingress case does not suffer from this problem because it usessendmsg_*(sk, msg) which does not pass the sk_buff further down thestack.The following splat was observed with 'test_progs -t sockmap_listen': [ 1022.710250][ T2556] general protection fault, ... [...] [ 1022.712830][ T2556] Workqueue: events sk_psock_backlog [ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80 [ 1022.713653][ T2556] Code: ... [...] [ 1022.720699][ T2556] Call Trace: [ 1022.720984][ T2556] [ 1022.721254][ T2556] ? die_addr+0x32/0x80^M [ 1022.721589][ T2556] ? exc_general_protection+0x25a/0x4b0 [ 1022.722026][ T2556] ? asm_exc_general_protection+0x22/0x30 [ 1022.722489][ T2556] ? skb_dequeue+0x4c/0x80 [ 1022.722854][ T2556] sk_psock_backlog+0x27a/0x300 [ 1022.723243][ T2556] process_one_work+0x2a7/0x5b0 [ 1022.723633][ T2556] worker_thread+0x4f/0x3a0 [ 1022.723998][ T2556] ? __pfx_worker_thread+0x10/0x10 [ 1022.724386][ T2556] kthread+0xfd/0x130 [ 1022.724709][ T2556] ? __pfx_kthread+0x10/0x10 [ 1022.725066][ T2556] ret_from_fork+0x2d/0x50 [ 1022.725409][ T2556] ? __pfx_kthread+0x10/0x10 [ 1022.725799][ T2556] ret_from_fork_asm+0x1b/0x30 [ 1022.726201][ T2556] To fix we add an skb_get() before passing the skb to be enqueued in theengress queue. This bumps the skb->users refcnt so that consume_skb()and kfree_skb will not immediately free the sk_buff. With this we canbe sure the skb is still around when we do the dequeue. Then we justneed to decrement the refcnt or free the skb in the backlog case whichwe do by calling kfree_skb() on the ingress case as well as the sendmsgcase.Before locking change from fixes tag we had the sock locked so wecouldn't race with user and there was no issue here.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53846 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on direct node in truncate_dnode()syzbot reports below bug:BUG: KASAN: slab-use-after-free in f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574Read of size 4 at addr ffff88802a25c000 by task syz-executor148/5000CPU: 1 PID: 5000 Comm: syz-executor148 Not tainted 6.4.0-rc7-syzkaller-00041-ge660abd551f1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574 truncate_dnode+0x229/0x2e0 fs/f2fs/node.c:944 f2fs_truncate_inode_blocks+0x64b/0xde0 fs/f2fs/node.c:1154 f2fs_do_truncate_blocks+0x4ac/0xf30 fs/f2fs/file.c:721 f2fs_truncate_blocks+0x7b/0x300 fs/f2fs/file.c:749 f2fs_truncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799 f2fs_truncate include/linux/fs.h:825 [inline] f2fs_setattr+0x1738/0x2090 fs/f2fs/file.c:1006 notify_change+0xb2c/0x1180 fs/attr.c:483 do_truncate+0x143/0x200 fs/open.c:66 handle_truncate fs/namei.c:3295 [inline] do_open fs/namei.c:3640 [inline] path_openat+0x2083/0x2750 fs/namei.c:3791 do_filp_open+0x1ba/0x410 fs/namei.c:3818 do_sys_openat2+0x16d/0x4c0 fs/open.c:1356 do_sys_open fs/open.c:1372 [inline] __do_sys_creat fs/open.c:1448 [inline] __se_sys_creat fs/open.c:1442 [inline] __x64_sys_creat+0xcd/0x120 fs/open.c:1442 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe root cause is, inodeA references inodeB via inodeB's ino, once inodeAis truncated, it calls truncate_dnode() to truncate data blocks in inodeB'snode page, it traverse mapping data from node->i.i_addr[0] tonode->i.i_addr[ADDRS_PER_BLOCK() - 1], result in out-of-boundary access.This patch fixes to add sanity check on dnode page in truncate_dnode(),so that, it can help to avoid triggering such issue, and once it encounterssuch issue, it will record newly introduced ERROR_INVALID_NODE_REFERENCEerror into superblock, later fsck can detect such issue and try repairing.Also, it removes f2fs_truncate_data_blocks() for cleanup due to thefunction has only one caller, and uses f2fs_truncate_data_blocks_range()instead.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: annotate accesses to nlk->cb_runningBoth netlink_recvmsg() and netlink_native_seq_show() readnlk->cb_running locklessly. Use READ_ONCE() there.Add corresponding WRITE_ONCE() to netlink_dump() and__netlink_dump_start()syzbot reported:BUG: KCSAN: data-race in __netlink_dump_start / netlink_recvmsgwrite to 0xffff88813ea4db59 of 1 bytes by task 28219 on cpu 0:__netlink_dump_start+0x3af/0x4d0 net/netlink/af_netlink.c:2399netlink_dump_start include/linux/netlink.h:308 [inline]rtnetlink_rcv_msg+0x70f/0x8c0 net/core/rtnetlink.c:6130netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2577rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6192netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0x56f/0x640 net/netlink/af_netlink.c:1365netlink_sendmsg+0x665/0x770 net/netlink/af_netlink.c:1942sock_sendmsg_nosec net/socket.c:724 [inline]sock_sendmsg net/socket.c:747 [inline]sock_write_iter+0x1aa/0x230 net/socket.c:1138call_write_iter include/linux/fs.h:1851 [inline]new_sync_write fs/read_write.c:491 [inline]vfs_write+0x463/0x760 fs/read_write.c:584ksys_write+0xeb/0x1a0 fs/read_write.c:637__do_sys_write fs/read_write.c:649 [inline]__se_sys_write fs/read_write.c:646 [inline]__x64_sys_write+0x42/0x50 fs/read_write.c:646do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff88813ea4db59 of 1 bytes by task 28222 on cpu 1:netlink_recvmsg+0x3b4/0x730 net/netlink/af_netlink.c:2022sock_recvmsg_nosec+0x4c/0x80 net/socket.c:1017____sys_recvmsg+0x2db/0x310 net/socket.c:2718___sys_recvmsg net/socket.c:2762 [inline]do_recvmmsg+0x2e5/0x710 net/socket.c:2856__sys_recvmmsg net/socket.c:2935 [inline]__do_sys_recvmmsg net/socket.c:2958 [inline]__se_sys_recvmmsg net/socket.c:2951 [inline]__x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x00 -> 0x01

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: ocelot: call dsa_tag_8021q_unregister() under rtnl_lock() on driver removeWhen the tagging protocol in current use is "ocelot-8021q" and we unbindthe driver, we see this splat:$ echo '0000:00:00.2' > /sys/bus/pci/drivers/fsl_enetc/unbindmscc_felix 0000:00:00.5 swp0: left promiscuous modesja1105 spi2.0: Link is DownDSA: tree 1 torn downmscc_felix 0000:00:00.5 swp2: left promiscuous modesja1105 spi2.2: Link is DownDSA: tree 3 torn downfsl_enetc 0000:00:00.2 eno2: left promiscuous modemscc_felix 0000:00:00.5: Link is Down------------[ cut here ]------------RTNL: assertion failed at net/dsa/tag_8021q.c (409)WARNING: CPU: 1 PID: 329 at net/dsa/tag_8021q.c:409 dsa_tag_8021q_unregister+0x12c/0x1a0Modules linked in:CPU: 1 PID: 329 Comm: bash Not tainted 6.5.0-rc3+ #771pc : dsa_tag_8021q_unregister+0x12c/0x1a0lr : dsa_tag_8021q_unregister+0x12c/0x1a0Call trace: dsa_tag_8021q_unregister+0x12c/0x1a0 felix_tag_8021q_teardown+0x130/0x150 felix_teardown+0x3c/0xd8 dsa_tree_teardown_switches+0xbc/0xe0 dsa_unregister_switch+0x168/0x260 felix_pci_remove+0x30/0x60 pci_device_remove+0x4c/0x100 device_release_driver_internal+0x188/0x288 device_links_unbind_consumers+0xfc/0x138 device_release_driver_internal+0xe0/0x288 device_driver_detach+0x24/0x38 unbind_store+0xd8/0x108 drv_attr_store+0x30/0x50---[ end trace 0000000000000000 ]---------------[ cut here ]------------RTNL: assertion failed at net/8021q/vlan_core.c (376)WARNING: CPU: 1 PID: 329 at net/8021q/vlan_core.c:376 vlan_vid_del+0x1b8/0x1f0CPU: 1 PID: 329 Comm: bash Tainted: G W 6.5.0-rc3+ #771pc : vlan_vid_del+0x1b8/0x1f0lr : vlan_vid_del+0x1b8/0x1f0 dsa_tag_8021q_unregister+0x8c/0x1a0 felix_tag_8021q_teardown+0x130/0x150 felix_teardown+0x3c/0xd8 dsa_tree_teardown_switches+0xbc/0xe0 dsa_unregister_switch+0x168/0x260 felix_pci_remove+0x30/0x60 pci_device_remove+0x4c/0x100 device_release_driver_internal+0x188/0x288 device_links_unbind_consumers+0xfc/0x138 device_release_driver_internal+0xe0/0x288 device_driver_detach+0x24/0x38 unbind_store+0xd8/0x108 drv_attr_store+0x30/0x50DSA: tree 0 torn downThis was somewhat not so easy to spot, because "ocelot-8021q" is not thedefault tagging protocol, and thus, not everyone who tests the unbindingpath may have switched to it beforehand. The defaultfelix_tag_npi_teardown() does not require rtnl_lock() to be held.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53856 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:of: overlay: Call of_changeset_init() earlyWhen of_overlay_fdt_apply() fails, the changeset may be partiallyapplied, and the caller is still expected to call of_overlay_remove() toclean up this partial state.However, of_overlay_apply() calls of_resolve_phandles() beforeinit_overlay_changeset(). Hence if the overlay fails to apply due to anunresolved symbol, the overlay_changeset.cset.entries list is stilluninitialized, and cleanup will crash with a NULL-pointer dereference inoverlay_removal_is_ok().Fix this by moving the call to of_changeset_init() frominit_overlay_changeset() to of_overlay_fdt_apply(), where all otherearly initialization is done.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: do not hard code device address lenth in fdb dumpssyzbot reports that some netdev devices do not have a six bytesaddress [1]Replace ETH_ALEN by dev->addr_len.[1] (Case of a device where dev->addr_len = 4)BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak in copyout+0xb8/0x100 lib/iov_iter.c:169instrument_copy_to_user include/linux/instrumented.h:114 [inline]copyout+0xb8/0x100 lib/iov_iter.c:169_copy_to_iter+0x6d8/0x1d00 lib/iov_iter.c:536copy_to_iter include/linux/uio.h:206 [inline]simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:513__skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:527skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]netlink_recvmsg+0x4ae/0x15a0 net/netlink/af_netlink.c:1970sock_recvmsg_nosec net/socket.c:1019 [inline]sock_recvmsg net/socket.c:1040 [inline]____sys_recvmsg+0x283/0x7f0 net/socket.c:2722___sys_recvmsg+0x223/0x840 net/socket.c:2764do_recvmmsg+0x4f9/0xfd0 net/socket.c:2858__sys_recvmmsg net/socket.c:2937 [inline]__do_sys_recvmmsg net/socket.c:2960 [inline]__se_sys_recvmmsg net/socket.c:2953 [inline]__x64_sys_recvmmsg+0x397/0x490 net/socket.c:2953do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was stored to memory at:__nla_put lib/nlattr.c:1009 [inline]nla_put+0x1c6/0x230 lib/nlattr.c:1067nlmsg_populate_fdb_fill+0x2b8/0x600 net/core/rtnetlink.c:4071nlmsg_populate_fdb net/core/rtnetlink.c:4418 [inline]ndo_dflt_fdb_dump+0x616/0x840 net/core/rtnetlink.c:4456rtnl_fdb_dump+0x14ff/0x1fc0 net/core/rtnetlink.c:4629netlink_dump+0x9d1/0x1310 net/netlink/af_netlink.c:2268netlink_recvmsg+0xc5c/0x15a0 net/netlink/af_netlink.c:1995sock_recvmsg_nosec+0x7a/0x120 net/socket.c:1019____sys_recvmsg+0x664/0x7f0 net/socket.c:2720___sys_recvmsg+0x223/0x840 net/socket.c:2764do_recvmmsg+0x4f9/0xfd0 net/socket.c:2858__sys_recvmmsg net/socket.c:2937 [inline]__do_sys_recvmmsg net/socket.c:2960 [inline]__se_sys_recvmmsg net/socket.c:2953 [inline]__x64_sys_recvmmsg+0x397/0x490 net/socket.c:2953do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at:slab_post_alloc_hook+0x12d/0xb60 mm/slab.h:716slab_alloc_node mm/slub.c:3451 [inline]__kmem_cache_alloc_node+0x4ff/0x8b0 mm/slub.c:3490kmalloc_trace+0x51/0x200 mm/slab_common.c:1057kmalloc include/linux/slab.h:559 [inline]__hw_addr_create net/core/dev_addr_lists.c:60 [inline]__hw_addr_add_ex+0x2e5/0x9e0 net/core/dev_addr_lists.c:118__dev_mc_add net/core/dev_addr_lists.c:867 [inline]dev_mc_add+0x9a/0x130 net/core/dev_addr_lists.c:885igmp6_group_added+0x267/0xbc0 net/ipv6/mcast.c:680ipv6_mc_up+0x296/0x3b0 net/ipv6/mcast.c:2754ipv6_mc_remap+0x1e/0x30 net/ipv6/mcast.c:2708addrconf_type_change net/ipv6/addrconf.c:3731 [inline]addrconf_notify+0x4d3/0x1d90 net/ipv6/addrconf.c:3699notifier_call_chain kernel/notifier.c:93 [inline]raw_notifier_call_chain+0xe4/0x430 kernel/notifier.c:461call_netdevice_notifiers_info net/core/dev.c:1935 [inline]call_netdevice_notifiers_extack net/core/dev.c:1973 [inline]call_netdevice_notifiers+0x1ee/0x2d0 net/core/dev.c:1987bond_enslave+0xccd/0x53f0 drivers/net/bonding/bond_main.c:1906do_set_master net/core/rtnetlink.c:2626 [inline]rtnl_newlink_create net/core/rtnetlink.c:3460 [inline]__rtnl_newlink net/core/rtnetlink.c:3660 [inline]rtnl_newlink+0x378c/0x40e0 net/core/rtnetlink.c:3673rtnetlink_rcv_msg+0x16a6/0x1840 net/core/rtnetlink.c:6395netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2546rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6413netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0xf28/0x1230 net/netlink/af_---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53865 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix warning when putting transaction with qgroups enabled after abortIf we have a transaction abort with qgroups enabled we get a warningtriggered when doing the final put on the transaction, like this: [552.6789] ------------[ cut here ]------------ [552.6815] WARNING: CPU: 4 PID: 81745 at fs/btrfs/transaction.c:144 btrfs_put_transaction+0x123/0x130 [btrfs] [552.6817] Modules linked in: btrfs blake2b_generic xor (...) [552.6819] CPU: 4 PID: 81745 Comm: btrfs-transacti Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [552.6819] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [552.6819] RIP: 0010:btrfs_put_transaction+0x123/0x130 [btrfs] [552.6821] Code: bd a0 01 00 (...) [552.6821] RSP: 0018:ffffa168c0527e28 EFLAGS: 00010286 [552.6821] RAX: ffff936042caed00 RBX: ffff93604a3eb448 RCX: 0000000000000000 [552.6821] RDX: ffff93606421b028 RSI: ffffffff92ff0878 RDI: ffff93606421b010 [552.6821] RBP: ffff93606421b000 R08: 0000000000000000 R09: ffffa168c0d07c20 [552.6821] R10: 0000000000000000 R11: ffff93608dc52950 R12: ffffa168c0527e70 [552.6821] R13: ffff93606421b000 R14: ffff93604a3eb420 R15: ffff93606421b028 [552.6821] FS: 0000000000000000(0000) GS:ffff93675fb00000(0000) knlGS:0000000000000000 [552.6821] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [552.6821] CR2: 0000558ad262b000 CR3: 000000014feda005 CR4: 0000000000370ee0 [552.6822] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [552.6822] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [552.6822] Call Trace: [552.6822] [552.6822] ? __warn+0x80/0x130 [552.6822] ? btrfs_put_transaction+0x123/0x130 [btrfs] [552.6824] ? report_bug+0x1f4/0x200 [552.6824] ? handle_bug+0x42/0x70 [552.6824] ? exc_invalid_op+0x14/0x70 [552.6824] ? asm_exc_invalid_op+0x16/0x20 [552.6824] ? btrfs_put_transaction+0x123/0x130 [btrfs] [552.6826] btrfs_cleanup_transaction+0xe7/0x5e0 [btrfs] [552.6828] ? _raw_spin_unlock_irqrestore+0x23/0x40 [552.6828] ? try_to_wake_up+0x94/0x5e0 [552.6828] ? __pfx_process_timeout+0x10/0x10 [552.6828] transaction_kthread+0x103/0x1d0 [btrfs] [552.6830] ? __pfx_transaction_kthread+0x10/0x10 [btrfs] [552.6832] kthread+0xee/0x120 [552.6832] ? __pfx_kthread+0x10/0x10 [552.6832] ret_from_fork+0x29/0x50 [552.6832] [552.6832] ---[ end trace 0000000000000000 ]---This corresponds to this line of code: void btrfs_put_transaction(struct btrfs_transaction *transaction) { (...) WARN_ON(!RB_EMPTY_ROOT( &transaction->delayed_refs.dirty_extent_root)); (...) }The warning happens because btrfs_qgroup_destroy_extent_records(), calledin the transaction abort path, we free all entries from the rbtree"dirty_extent_root" with rbtree_postorder_for_each_entry_safe(), but wedon't actually empty the rbtree - it's still pointing to nodes that werefreed.So set the rbtree's root node to NULL to avoid this warning (assignRB_ROOT).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53867 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix potential use-after-free bug when trimming capsWhen trimming the caps and just after the 'session->s_cap_lock' isreleased in ceph_iterate_session_caps() the cap maybe removed byanother thread, and when using the stale cap memory in the callbacksit will trigger use-after-free crash.We need to check the existence of the cap just after the 'ci->i_ceph_lock'being acquired. And do nothing if it's already removed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53986 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mips: bmips: BCM6358: disable RAC flush for TP1RAC flush causes kernel panics on BCM6358 with EHCI/OHCI when booting from TP1:[ 3.881739] usb 1-1: new high-speed USB device number 2 using ehci-platform[ 3.895011] Reserved instruction in kernel code[#1]:[ 3.900113] CPU: 0 PID: 1 Comm: init Not tainted 5.10.16 #0[ 3.905829] $ 0 : 00000000 10008700 00000000 77d94060[ 3.911238] $ 4 : 7fd1f088 00000000 81431cac 81431ca0[ 3.916641] $ 8 : 00000000 ffffefff 8075cd34 00000000[ 3.922043] $12 : 806f8d40 f3e812b7 00000000 000d9aaa[ 3.927446] $16 : 7fd1f068 7fd1f080 7ff559b8 81428470[ 3.932848] $20 : 00000000 00000000 55590000 77d70000[ 3.938251] $24 : 00000018 00000010[ 3.943655] $28 : 81430000 81431e60 81431f28 800157fc[ 3.949058] Hi : 00000000[ 3.952013] Lo : 00000000[ 3.955019] epc : 80015808 setup_sigcontext+0x54/0x24c[ 3.960464] ra : 800157fc setup_sigcontext+0x48/0x24c[ 3.965913] Status: 10008703 KERNEL EXL IE[ 3.970216] Cause : 00800028 (ExcCode 0a)[ 3.974340] PrId : 0002a010 (Broadcom BMIPS4350)[ 3.979170] Modules linked in: ohci_platform ohci_hcd fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug usbcore nls_base usb_common[ 3.992907] Process init (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=77e22ec8)[ 4.000776] Stack : 81431ef4 7fd1f080 81431f28 81428470 7fd1f068 81431edc 7ff559b8 81428470[ 4.009467] 81431f28 7fd1f080 55590000 77d70000 77d5498c 80015c70 806f0000 8063ae74[ 4.018149] 08100002 81431f28 0000000a 08100002 81431f28 0000000a 77d6b418 00000003[ 4.026831] ffffffff 80016414 80080734 81431ecc 81431ecc 00000001 00000000 04000000[ 4.035512] 77d54874 00000000 00000000 00000000 00000000 00000012 00000002 00000000[ 4.044196] ...[ 4.046706] Call Trace:[ 4.049238] [<80015808>] setup_sigcontext+0x54/0x24c[ 4.054356] [<80015c70>] setup_frame+0xdc/0x124[ 4.059015] [<80016414>] do_notify_resume+0x1dc/0x288[ 4.064207] [<80011b50>] work_notifysig+0x10/0x18[ 4.069036][ 4.070538] Code: 8fc300b4 00001025 26240008 ac830004 3c048063 0c0228aa 24846a00 26240010[ 4.080686][ 4.082517] ---[ end trace 22a8edb41f5f983b ]---[ 4.087374] Kernel panic - not syncing: Fatal exception[ 4.092753] Rebooting in 1 seconds..Because the bootloader (CFE) is not initializing the Read-ahead cache properlyon the second thread (TP1). Since the RAC was not initialized properly, weshould avoid flushing it at the risk of corrupting the instruction stream asseen in the trace above.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53989 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: mm: fix VA-range sanity checkBoth create_mapping_noalloc() and update_mapping_prot() sanity-checktheir 'virt' parameter, but the check itself doesn't make much sense.The condition used today appears to be a historical accident.The sanity-check condition: if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }... can only be true for the KASAN shadow region or the module region,and there's no reason to exclude these specifically for creating andupdateing mappings.When arm64 support was first upstreamed in commit: c1cc1552616d0f35 ("arm64: MMU initialisation")... the condition was: if (virt < VMALLOC_START) { [ ... warning here ... ] return; }At the time, VMALLOC_START was the lowest kernel address, and this waschecking whether 'virt' would be translated via TTBR1.Subsequently in commit: 14c127c957c1c607 ("arm64: mm: Flip kernel VA space")... the condition was changed to: if ((virt >= VA_START) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }This appear to have been a thinko. The commit moved the linear map tothe bottom of the kernel address space, with VMALLOC_START being at thehalfway point. The old condition would warn for changes to the linearmap below this, and at the time VA_START was the end of the linear map.Subsequently we cleaned up the naming of VA_START in commit: 77ad4ce69321abbe ("arm64: memory: rename VA_START to PAGE_END")... keeping the erroneous condition as: if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }Correct the condition to check against the start of the TTBR1 addressspace, which is currently PAGE_OFFSET. This simplifies the logic, andmore clearly matches the "outside kernel range" message in the warning.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-53994 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ionic: remove WARN_ON to prevent panic_on_warnRemove unnecessary early code development check and the WARN_ONthat it uses. The irq alloc and free paths have long beencleaned up and this check shouldn't have stuck around so long.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54004 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while usingIPPROTO_UDPLITE (0x88): 14:25:52 executing program 1: r0 = socket$inet6(0xa, 0x80002, 0x88)We had a similar report [1] for probably sk_memory_allocated_add()in __sk_mem_raise_allocated(), and commit c915fe13cbaa ("udplite: fixNULL pointer dereference") fixed it by setting .memory_allocated forudplite_prot and udplitev6_prot.To fix the variant, we need to set either .sysctl_wmem_offset or.sysctl_rmem.Now UDP and UDPLITE share the same value for .memory_allocated, so weuse the same .sysctl_wmem_offset for UDP and UDPLITE.[0]:general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023RIP: 0010:sk_get_rmem0 include/net/sock.h:2907 [inline]RIP: 0010:__sk_mem_raise_allocated+0x806/0x17a0 net/core/sock.c:3006Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8bRSP: 0018:ffffc90005d7f450 EFLAGS: 00010246RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001FS: 0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0Call Trace: __sk_mem_schedule+0x6c/0xe0 net/core/sock.c:3077 udp_rmem_schedule net/ipv4/udp.c:1539 [inline] __udp_enqueue_schedule_skb+0x776/0xb30 net/ipv4/udp.c:1581 __udpv6_queue_rcv_skb net/ipv6/udp.c:666 [inline] udpv6_queue_rcv_one_skb+0xc39/0x16c0 net/ipv6/udp.c:775 udpv6_queue_rcv_skb+0x194/0xa10 net/ipv6/udp.c:793 __udp6_lib_mcast_deliver net/ipv6/udp.c:906 [inline] __udp6_lib_rcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013 ip6_protocol_deliver_rcu+0x2e7/0x1250 net/ipv6/ip6_input.c:437 ip6_input_finish+0x150/0x2f0 net/ipv6/ip6_input.c:482 NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ip6_input+0xa0/0xd0 net/ipv6/ip6_input.c:491 ip6_mc_input+0x40b/0xf50 net/ipv6/ip6_input.c:585 dst_input include/net/dst.h:468 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ipv6_rcv+0x250/0x380 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491 __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605 netif_receive_skb_internal net/core/dev.c:5691 [inline] netif_receive_skb+0x133/0x7a0 net/core/dev.c:5750 tun_rx_batched+0x4b3/0x7a0 drivers/net/tun.c:1553 tun_get_user+0x2452/0x39c0 drivers/net/tun.c:1989 tun_chr_write_iter+0xdf/0x200 drivers/net/tun.c:2035 call_write_iter include/linux/fs.h:1868 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x945/0xd50 fs/read_write.c:584 ksys_write+0x12b/0x250 fs/read_write.c:637 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82RIP: 0023:0xf7f21579Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54005 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:binder: fix memory leak in binder_init()In binder_init(), the destruction of binder_alloc_shrinker_init() is notperformed in the wrong path, which will cause memory leaks. So this commitintroduces binder_alloc_shrinker_exit() and calls it in the wrong path tofix that.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54012 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix stack overflow when LRO is disabled for virtual interfacesWhen the virtual interface's feature is updated, it synchronizes theupdated feature for its own lower interface.This propagation logic should be worked as the iteration, not recursively.But it works recursively due to the netdev notification unexpectedly.This problem occurs when it disables LRO only for the team and bondinginterface type. team0 | +------+------+-----+-----+ | | | | |team1 team2 team3 ... team200If team0's LRO feature is updated, it generates the NETDEV_FEAT_CHANGEevent to its own lower interfaces(team1 ~ team200).It is worked by netdev_sync_lower_features().So, the NETDEV_FEAT_CHANGE notification logic of each lower interfacework iteratively.But generated NETDEV_FEAT_CHANGE event is also sent to the upperinterface too.upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its ownlower interfaces again.lower and upper interfaces receive this event and generate thisevent again and again.So, the stack overflow occurs.But it is not the infinite loop issue.Because the netdev_sync_lower_features() updates features beforegenerating the NETDEV_FEAT_CHANGE event.Already synchronized lower interfaces skip notification logic.So, it is just the problem that iteration logic is changed to therecursive unexpectedly due to the notification mechanism.Reproducer:ip link add team0 type teamethtool -K team0 lro onfor i in {1..200}do ip link add team$i master team0 type team ethtool -K team$i lro ondoneethtool -K team0 lro offIn order to fix it, the notifier_ctx member of bonding/team is introduced.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54023 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race between balance and cancel/pauseSyzbot reported a panic that looks like this: assertion failed: fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465 ------------[ cut here ]------------ kernel BUG at fs/btrfs/messages.c:259! RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259 Call Trace: btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline] btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline] btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe reproducer is running a balance and a cancel or pause in parallel.The way balance finishes is a bit wonky, if we were paused we need tosave the balance_ctl in the fs_info, but clear it otherwise and cleanup.However we rely on the return values being specific errors, or having acancel request or no pause request. If balance completes and returns 0,but we have a pause or cancel request we won't do the appropriatecleanup, and then the next time we try to start a balance we'll tripthis ASSERT.The error handling is just wrong here, we always want to clean up,unless we got -ECANCELLED and we set the appropriate pause flag in theexclusive op. With this patch the reproducer ran for an hour withouttripping, previously it would trip in less than a few minutes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54032 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race when deleting quota root from the dirty cow roots listWhen disabling quotas we are deleting the quota root from the listfs_info->dirty_cowonly_roots without taking the lock that protects it,which is struct btrfs_fs_info::trans_lock. This unsynchronized listmanipulation may cause chaos if there's another concurrent manipulationof this list, such as when adding a root to it withctree.c:add_root_to_dirty_list().This can result in all sorts of weird failures caused by a race, such asthe following crash: [337571.278245] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI [337571.278933] CPU: 1 PID: 115447 Comm: btrfs Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [337571.279153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [337571.279572] RIP: 0010:commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.279928] Code: 85 38 06 00 (...) [337571.280363] RSP: 0018:ffff9f63446efba0 EFLAGS: 00010206 [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX: 0000000449e1c000 [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070 [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000015b [337571.281254] R10: 0000000000000009 R11: 0000000000000001 R12: ffff942fe8fbf600 [337571.281476] R13: ffff942dabe23040 R14: ffff942dabe20800 R15: ffff942d92cf3b48 [337571.281723] FS: 00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000 [337571.281950] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0 [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [337571.282647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [337571.282874] Call Trace: [337571.283101] [337571.283327] ? __die_body+0x1b/0x60 [337571.283570] ? die_addr+0x39/0x60 [337571.283796] ? exc_general_protection+0x22e/0x430 [337571.284022] ? asm_exc_general_protection+0x22/0x30 [337571.284251] ? commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.284531] btrfs_commit_transaction+0x42e/0xf90 [btrfs] [337571.284803] ? _raw_spin_unlock+0x15/0x30 [337571.285031] ? release_extent_buffer+0x103/0x130 [btrfs] [337571.285305] reset_balance_state+0x152/0x1b0 [btrfs] [337571.285578] btrfs_balance+0xa50/0x11e0 [btrfs] [337571.285864] ? __kmem_cache_alloc_node+0x14a/0x410 [337571.286086] btrfs_ioctl+0x249a/0x3320 [btrfs] [337571.286358] ? mod_objcg_state+0xd2/0x360 [337571.286577] ? refill_obj_stock+0xb0/0x160 [337571.286798] ? seq_release+0x25/0x30 [337571.287016] ? __rseq_handle_notify_resume+0x3ba/0x4b0 [337571.287235] ? percpu_counter_add_batch+0x2e/0xa0 [337571.287455] ? __x64_sys_ioctl+0x88/0xc0 [337571.287675] __x64_sys_ioctl+0x88/0xc0 [337571.287901] do_syscall_64+0x38/0x90 [337571.288126] entry_SYSCALL_64_after_hwframe+0x72/0xdc [337571.288352] RIP: 0033:0x7f478aaffe9bSo fix this by locking struct btrfs_fs_info::trans_lock before deletingthe quota root from that list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54033 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix a memory leak in the LRU and LRU_PERCPU hash mapsThe LRU and LRU_PERCPU maps allocate a new element on update before locking thetarget hash table bucket. Right after that the maps try to lock the bucket.If this fails, then maps return -EBUSY to the caller without releasing theallocated element. This makes the element untracked: it doesn't belong toeither of free lists, and it doesn't belong to the hash table, so can't bere-used; this eventually leads to the permanent -ENOMEM on LRU map updates,which is unexpected. Fix this by returning the element to the local free listif bucket locking fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54047 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/rockchip: dw_hdmi: cleanup drm encoder during unbindThis fixes a use-after-free crash during rmmod.The DRM encoder is embedded inside the larger rockchip_hdmi,which is allocated with the component. The component memorygets freed before the main drm device is destroyed. Fix itby running encoder cleanup before tearing down its container.[moved encoder cleanup above clk_disable, similar to bind-error-path]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54052 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7921: fix skb leak by txs missing in AMSDUtxs may be dropped if the frame is aggregated in AMSDU. When the problemshows up, some SKBs would be hold in driver to cause network stoppedtemporarily. Even if the problem can be recovered by txs timeout handling,mt7921 still need to disable txs in AMSDU to avoid this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54056 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kheaders: Use array declaration instead of charUnder CONFIG_FORTIFY_SOURCE, memcpy() will check the size of destinationand source buffers. Defining kernel_headers_data as "char" would tripthis check. Since these addresses are treated as byte arrays, definethem as arrays (as done everywhere else).This was seen with: $ cat /sys/kernel/kheaders.tar.xz >> /dev/null detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1027! ... RIP: 0010:fortify_panic+0xf/0x20 [...] Call Trace: ikheaders_read+0x45/0x50 [kheaders] kernfs_fop_read_iter+0x1a4/0x2f0 ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54057 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Add a length limitation for the ivrs_acpihid command-line parameterThe 'acpiid' buffer in the parse_ivrs_acpihid function may overflow,because the string specifier in the format string sscanf()has no width limitation.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54066 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb-v2: gl861: Fix null-ptr-deref in gl861_i2c_master_xferIn gl861_i2c_master_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach gl861_i2c_master_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54067 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race when deleting free space root from the dirty cow roots listWhen deleting the free space tree we are deleting the free space rootfrom the list fs_info->dirty_cowonly_roots without taking the lock thatprotects it, which is struct btrfs_fs_info::trans_lock.This unsynchronized list manipulation may cause chaos if there's anotherconcurrent manipulation of this list, such as when adding a root to itwith ctree.c:add_root_to_dirty_list().This can result in all sorts of weird failures caused by a race, such asthe following crash: [337571.278245] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI [337571.278933] CPU: 1 PID: 115447 Comm: btrfs Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [337571.279153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [337571.279572] RIP: 0010:commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.279928] Code: 85 38 06 00 (...) [337571.280363] RSP: 0018:ffff9f63446efba0 EFLAGS: 00010206 [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX: 0000000449e1c000 [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070 [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000015b [337571.281254] R10: 0000000000000009 R11: 0000000000000001 R12: ffff942fe8fbf600 [337571.281476] R13: ffff942dabe23040 R14: ffff942dabe20800 R15: ffff942d92cf3b48 [337571.281723] FS: 00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000 [337571.281950] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0 [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [337571.282647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [337571.282874] Call Trace: [337571.283101] [337571.283327] ? __die_body+0x1b/0x60 [337571.283570] ? die_addr+0x39/0x60 [337571.283796] ? exc_general_protection+0x22e/0x430 [337571.284022] ? asm_exc_general_protection+0x22/0x30 [337571.284251] ? commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.284531] btrfs_commit_transaction+0x42e/0xf90 [btrfs] [337571.284803] ? _raw_spin_unlock+0x15/0x30 [337571.285031] ? release_extent_buffer+0x103/0x130 [btrfs] [337571.285305] reset_balance_state+0x152/0x1b0 [btrfs] [337571.285578] btrfs_balance+0xa50/0x11e0 [btrfs] [337571.285864] ? __kmem_cache_alloc_node+0x14a/0x410 [337571.286086] btrfs_ioctl+0x249a/0x3320 [btrfs] [337571.286358] ? mod_objcg_state+0xd2/0x360 [337571.286577] ? refill_obj_stock+0xb0/0x160 [337571.286798] ? seq_release+0x25/0x30 [337571.287016] ? __rseq_handle_notify_resume+0x3ba/0x4b0 [337571.287235] ? percpu_counter_add_batch+0x2e/0xa0 [337571.287455] ? __x64_sys_ioctl+0x88/0xc0 [337571.287675] __x64_sys_ioctl+0x88/0xc0 [337571.287901] do_syscall_64+0x38/0x90 [337571.288126] entry_SYSCALL_64_after_hwframe+0x72/0xdc [337571.288352] RIP: 0033:0x7f478aaffe9bSo fix this by locking struct btrfs_fs_info::trans_lock before deletingthe free space root from that list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54070 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:igb: clean up in all error paths when enabling SR-IOVAfter commit 50f303496d92 ("igb: Enable SR-IOV after reinit"), removingthe igb module could hang or crash (depending on the machine) when themodule has been loaded with the max_vfs parameter set to some value != 0.In case of one test machine with a dual port 82580, this hang occurred:[ 232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1[ 233.093257] igb 0000:41:00.1: IOV Disabled[ 233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0[ 233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata)[ 233.352248] igb 0000:41:00.0: device [8086:1516] error status/mask=00100000[ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First)[ 233.368183] igb 0000:41:00.0: AER: TLP Header: 40000001 0000040f cdbfc00c c[ 233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata)[ 233.388779] igb 0000:41:00.1: device [8086:1516] error status/mask=00100000[ 233.397629] igb 0000:41:00.1: [20] UnsupReq (First)[ 233.404736] igb 0000:41:00.1: AER: TLP Header: 40000001 0000040f cdbfc00c c[ 233.538214] pci 0000:41:00.1: AER: can't recover (no error_detected callback)[ 233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0[ 233.546197] pcieport 0000:40:01.0: AER: device recovery failed[ 234.157244] igb 0000:41:00.0: IOV Disabled[ 371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds.[ 371.627489] Not tainted 6.4.0-dirty #2[ 371.632257] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this.[ 371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0[ 371.650330] Call Trace:[ 371.653061] [ 371.655407] __schedule+0x20e/0x660[ 371.659313] schedule+0x5a/0xd0[ 371.662824] schedule_preempt_disabled+0x11/0x20[ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0[ 371.673237] ? __pfx_aer_root_reset+0x10/0x10[ 371.678105] report_error_detected+0x25/0x1c0[ 371.682974] ? __pfx_report_normal_detected+0x10/0x10[ 371.688618] pci_walk_bus+0x72/0x90[ 371.692519] pcie_do_recovery+0xb2/0x330[ 371.696899] aer_process_err_devices+0x117/0x170[ 371.702055] aer_isr+0x1c0/0x1e0[ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0[ 371.710723] ? __pfx_irq_thread_fn+0x10/0x10[ 371.715496] irq_thread_fn+0x20/0x60[ 371.719491] irq_thread+0xe6/0x1b0[ 371.723291] ? __pfx_irq_thread_dtor+0x10/0x10[ 371.728255] ? __pfx_irq_thread+0x10/0x10[ 371.732731] kthread+0xe2/0x110[ 371.736243] ? __pfx_kthread+0x10/0x10[ 371.740430] ret_from_fork+0x2c/0x50[ 371.744428] The reproducer was a simple script: #!/bin/sh for i in `seq 1 5`; do modprobe -rv igb modprobe -v igb max_vfs=1 sleep 1 modprobe -rv igb doneIt turned out that this could only be reproduce on 82580 (quad anddual-port), but not on 82576, i350 and i210. Further debugging showedthat igb_enable_sriov()'s call to pci_enable_sriov() is failing, becausedev->is_physfn is 0 on 82580.Prior to commit 50f303496d92 ("igb: Enable SR-IOV after reinit"),igb_enable_sriov() jumped into the "err_out" cleanup branch. After thiscommit it only returned the error code.So the cleanup didn't take place, and the incorrect VF setup in theigb_adapter structure fooled the igb driver into assuming that VFs havebeen set up where no VF actually existed.Fix this problem by cleaning up again if pci_enable_sriov() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54081 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xen: speed up grant-table reclaimWhen a grant entry is still in use by the remote domain, Linux must putit on a deferred list. Normally, this list is very short, becausethe PV network and block protocols expect the backend to unmap the grantfirst. However, Qubes OS's GUI protocol is subject to the constraintsof the X Window System, and as such winds up with the frontend unmappingthe window first. As a result, the list can grow very large, resultingin a massive memory leak and eventual VM freeze.To partially solve this problem, make the number of entries that the VMwill attempt to free at each iteration tunable. The default is still10, but it can be overridden via a module parameter.This is Cc: stable because (when combined with appropriate userspacechanges) it fixes a severe performance and stability problem for QubesOS users.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54086 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Add preempt_count_{sub,add} into btf id deny listThe recursion check in __bpf_prog_enter* and __bpf_prog_exit*leave preempt_count_{sub,add} unprotected. When attaching trampoline tothem we get panic as follows,[ 867.843050] BUG: TASK stack guard page was hit at 0000000009d325cf (stack is 0000000046a46a15..00000000537e7b28)[ 867.843064] stack guard page: 0000 [#1] PREEMPT SMP NOPTI[ 867.843067] CPU: 8 PID: 11009 Comm: trace Kdump: loaded Not tainted 6.2.0+ #4[ 867.843100] Call Trace:[ 867.843101] [ 867.843104] asm_exc_int3+0x3a/0x40[ 867.843108] RIP: 0010:preempt_count_sub+0x1/0xa0[ 867.843135] __bpf_prog_enter_recur+0x17/0x90[ 867.843148] bpf_trampoline_6442468108_0+0x2e/0x1000[ 867.843154] ? preempt_count_sub+0x1/0xa0[ 867.843157] preempt_count_sub+0x5/0xa0[ 867.843159] ? migrate_enable+0xac/0xf0[ 867.843164] __bpf_prog_exit_recur+0x2d/0x40[ 867.843168] bpf_trampoline_6442468108_0+0x55/0x1000...[ 867.843788] preempt_count_sub+0x5/0xa0[ 867.843793] ? migrate_enable+0xac/0xf0[ 867.843829] __bpf_prog_exit_recur+0x2d/0x40[ 867.843837] BUG: IRQ stack guard page was hit at 0000000099bd8228 (stack is 00000000b23e2bc4..000000006d95af35)[ 867.843841] BUG: IRQ stack guard page was hit at 000000005ae07924 (stack is 00000000ffd69623..0000000014eb594c)[ 867.843843] BUG: IRQ stack guard page was hit at 00000000028320f0 (stack is 00000000034b6438..0000000078d1bcec)[ 867.843842] bpf_trampoline_6442468108_0+0x55/0x1000...That is because in __bpf_prog_exit_recur, the preempt_count_{sub,add} arecalled after prog->active is decreased.Fixing this by adding these two functions into btf ids deny list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54087 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix possible null-ptr-deref in ubi_free_volume()It willl cause null-ptr-deref in the following case:uif_init() ubi_add_volume() cdev_add() -> if it fails, call kill_volumes() device_register()kill_volumes() -> if ubi_add_volume() fails call this function ubi_free_volume() cdev_del() device_unregister() -> trying to delete a not added device, it causes null-ptr-derefSo in ubi_free_volume(), it delete devices whether they are addedor not, it will causes null-ptr-deref.Handle the error case whlie calling ubi_add_volume() to fix thisproblem. If add volume fails, set the corresponding vol to null,so it can not be accessed in kill_volumes() and release theresource in ubi_add_volume() error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54093 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: anysee: fix null-ptr-deref in anysee_master_xferIn anysee_master_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach anysee_master_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")[hverkuil: add spaces around +]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54094 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: prevent skb corruption on frag list segmentationIan reported several skb corruptions triggered by rx-gro-list,collecting different oops alike:[ 62.624003] BUG: kernel NULL pointer dereference, address: 00000000000000c0[ 62.631083] #PF: supervisor read access in kernel mode[ 62.636312] #PF: error_code(0x0000) - not-present page[ 62.641541] PGD 0 P4D 0[ 62.644174] Oops: 0000 [#1] PREEMPT SMP NOPTI[ 62.648629] CPU: 1 PID: 913 Comm: napi/eno2-79 Not tainted 6.4.0 #364[ 62.655162] Hardware name: Supermicro Super Server/A2SDi-12C-HLN4F, BIOS 1.7a 10/13/2022[ 62.663344] RIP: 0010:__udp_gso_segment (./include/linux/skbuff.h:2858./include/linux/udp.h:23 net/ipv4/udp_offload.c:228 net/ipv4/udp_offload.c:261net/ipv4/udp_offload.c:277)[ 62.687193] RSP: 0018:ffffbd3a83b4f868 EFLAGS: 00010246[ 62.692515] RAX: 00000000000000ce RBX: 0000000000000000 RCX: 0000000000000000[ 62.699743] RDX: ffffa124def8a000 RSI: 0000000000000079 RDI: ffffa125952a14d4[ 62.706970] RBP: ffffa124def8a000 R08: 0000000000000022 R09: 00002000001558c9[ 62.714199] R10: 0000000000000000 R11: 00000000be554639 R12: 00000000000000e2[ 62.721426] R13: ffffa125952a1400 R14: ffffa125952a1400 R15: 00002000001558c9[ 62.728654] FS: 0000000000000000(0000) GS:ffffa127efa40000(0000)knlGS:0000000000000000[ 62.736852] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 62.742702] CR2: 00000000000000c0 CR3: 00000001034b0000 CR4: 00000000003526e0[ 62.749948] Call Trace:[ 62.752498] [ 62.779267] inet_gso_segment (net/ipv4/af_inet.c:1398)[ 62.787605] skb_mac_gso_segment (net/core/gro.c:141)[ 62.791906] __skb_gso_segment (net/core/dev.c:3403 (discriminator 2))[ 62.800492] validate_xmit_skb (./include/linux/netdevice.h:4862net/core/dev.c:3659)[ 62.804695] validate_xmit_skb_list (net/core/dev.c:3710)[ 62.809158] sch_direct_xmit (net/sched/sch_generic.c:330)[ 62.813198] __dev_queue_xmit (net/core/dev.c:3805 net/core/dev.c:4210)net/netfilter/core.c:626)[ 62.821093] br_dev_queue_push_xmit (net/bridge/br_forward.c:55)[ 62.825652] maybe_deliver (net/bridge/br_forward.c:193)[ 62.829420] br_flood (net/bridge/br_forward.c:233)[ 62.832758] br_handle_frame_finish (net/bridge/br_input.c:215)[ 62.837403] br_handle_frame (net/bridge/br_input.c:298net/bridge/br_input.c:416)[ 62.851417] __netif_receive_skb_core.constprop.0 (net/core/dev.c:5387)[ 62.866114] __netif_receive_skb_list_core (net/core/dev.c:5570)[ 62.871367] netif_receive_skb_list_internal (net/core/dev.c:5638net/core/dev.c:5727)[ 62.876795] napi_complete_done (./include/linux/list.h:37./include/net/gro.h:434 ./include/net/gro.h:429 net/core/dev.c:6067)[ 62.881004] ixgbe_poll (drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:3191)[ 62.893534] __napi_poll (net/core/dev.c:6498)[ 62.897133] napi_threaded_poll (./include/linux/netpoll.h:89net/core/dev.c:6640)[ 62.905276] kthread (kernel/kthread.c:379)[ 62.913435] ret_from_fork (arch/x86/entry/entry_64.S:314)[ 62.917119] In the critical scenario, rx-gro-list GRO-ed packets are fed, via abridge, both to the local input path and to an egress device (tun).The segmentation of such packets unsafely writes to the cloned skbswith shared heads.This change addresses the issue by uncloning as needed theto-be-segmented skbs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54099 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs: Protect reconfiguration of sb read-write from racing writesThe reconfigure / remount code takes a lot of effort to protectfilesystem's reconfiguration code from racing writes on remountingread-only. However during remounting read-only filesystem to read-writemode userspace writes can start immediately once we clear SB_RDONLYflag. This is inconvenient for example for ext4 because we need to dosome writes to the filesystem (such as preparation of quota files)before we can take userspace writes so we are clearing SB_RDONLY flagbefore we are fully ready to accept userpace writes and syzbot has founda way to exploit this [1]. Also as far as I'm reading the codethe filesystem remount code was protected from racing writes in thelegacy mount path by the mount's MNT_READONLY flag so this is relativelynew problem. It is actually fairly easy to protect remount read-writefrom racing writes using sb->s_readonly_remount flag so let's just dothat instead of having to workaround these races in the filesystem code.[1] https://lore.kernel.org/all/00000000000006a0df05f6667499@google.com/T/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54109 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: rcar_fdp1: Fix refcount leak in probe and remove functionrcar_fcp_get() take reference, which should be balanced withrcar_fcp_put(). Add missing rcar_fcp_put() in fdp1_remove andthe error paths of fdp1_probe() to fix this.[hverkuil: resolve merge conflict, remove() is now void]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54112 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kcm: Fix memory leak in error path of kcm_sendmsg()syzbot reported a memory leak like below:BUG: memory leakunreferenced object 0xffff88810b088c00 (size 240): comm "syz-executor186", pid 5012, jiffies 4294943306 (age 13.680s) hex dump (first 32 bytes): 00 89 08 0b 81 88 ff ff 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: [] __alloc_skb+0x1ef/0x230 net/core/skbuff.c:634 [] alloc_skb include/linux/skbuff.h:1289 [inline] [] kcm_sendmsg+0x269/0x1050 net/kcm/kcmsock.c:815 [] sock_sendmsg_nosec net/socket.c:725 [inline] [] sock_sendmsg+0x56/0xb0 net/socket.c:748 [] ____sys_sendmsg+0x365/0x470 net/socket.c:2494 [] ___sys_sendmsg+0xc9/0x130 net/socket.c:2548 [] __sys_sendmsg+0xa6/0x120 net/socket.c:2577 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcdIn kcm_sendmsg(), kcm_tx_msg(head)->last_skb is used as a cursor to appendnewly allocated skbs to 'head'. If some bytes are copied, an error occurred,and jumped to out_error label, 'last_skb' is left unmodified. A laterkcm_sendmsg() will use an obsoleted 'last_skb' reference, corrupting the'head' frag_list and causing the leak.This patch fixes this issue by properly updating the last allocated skb in'last_skb'.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54113 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcu: dump vmalloc memory info safelyCurrently, for double invoke call_rcu(), will dump rcu_head objects memoryinfo, if the objects is not allocated from the slab allocator, thevmalloc_dump_obj() will be invoke and the vmap_area_lock spinlock need tobe held, since the call_rcu() can be invoked in interrupt context,therefore, there is a possibility of spinlock deadlock scenarios.And in Preempt-RT kernel, the rcutorture test also trigger the followinglockdep warning:BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0preempt_count: 1, expected: 0RCU nest depth: 1, expected: 13 locks held by swapper/0/1: #0: ffffffffb534ee80 (fullstop_mutex){+.+.}-{4:4}, at: torture_init_begin+0x24/0xa0 #1: ffffffffb5307940 (rcu_read_lock){....}-{1:3}, at: rcu_torture_init+0x1ec7/0x2370 #2: ffffffffb536af40 (vmap_area_lock){+.+.}-{3:3}, at: find_vmap_area+0x1f/0x70irq event stamp: 565512hardirqs last enabled at (565511): [] __call_rcu_common+0x218/0x940hardirqs last disabled at (565512): [] rcu_torture_init+0x20b2/0x2370softirqs last enabled at (399112): [] __local_bh_enable_ip+0x126/0x170softirqs last disabled at (399106): [] inet_register_protosw+0x9/0x1d0Preemption disabled at:[] rcu_torture_init+0x1f13/0x2370CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.5.0-rc4-rt2-yocto-preempt-rt+ #15Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x68/0xb0 dump_stack+0x14/0x20 __might_resched+0x1aa/0x280 ? __pfx_rcu_torture_err_cb+0x10/0x10 rt_spin_lock+0x53/0x130 ? find_vmap_area+0x1f/0x70 find_vmap_area+0x1f/0x70 vmalloc_dump_obj+0x20/0x60 mem_dump_obj+0x22/0x90 __call_rcu_common+0x5bf/0x940 ? debug_smp_processor_id+0x1b/0x30 call_rcu_hurry+0x14/0x20 rcu_torture_init+0x1f82/0x2370 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_init+0x10/0x10 do_one_initcall+0x6c/0x300 ? debug_smp_processor_id+0x1b/0x30 kernel_init_freeable+0x2b9/0x540 ? __pfx_kernel_init+0x10/0x10 kernel_init+0x1f/0x150 ret_from_fork+0x40/0x50 ? __pfx_kernel_init+0x10/0x10 ret_from_fork_asm+0x1b/0x30 The previous patch fixes this by using the deadlock-safe best-effortversion of find_vm_area. However, in case of failure print the fact thatthe pointer was a vmalloc pointer so that we print at least something.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54114 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: nsh: Use correct mac_offset to unwind gso skb in nsh_gso_segment()As the call trace shows, skb_panic was caused by wrong skb->mac_headerin nsh_gso_segment():invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 3 PID: 2737 Comm: syz Not tainted 6.3.0-next-20230505 #1RIP: 0010:skb_panic+0xda/0xe0call Trace: skb_push+0x91/0xa0 nsh_gso_segment+0x4f3/0x570 skb_mac_gso_segment+0x19e/0x270 __skb_gso_segment+0x1e8/0x3c0 validate_xmit_skb+0x452/0x890 validate_xmit_skb_list+0x99/0xd0 sch_direct_xmit+0x294/0x7c0 __dev_queue_xmit+0x16f0/0x1d70 packet_xmit+0x185/0x210 packet_snd+0xc15/0x1170 packet_sendmsg+0x7b/0xa0 sock_sendmsg+0x14f/0x160The root cause is:nsh_gso_segment() use skb->network_header - nhoff to reset mac_headerin skb_gso_error_unwind() if inner-layer protocol gso fails.However, skb->network_header may be reset by inner-layer protocolgso function e.g. mpls_gso_segment. skb->mac_header reset by theinaccurate network_header will be larger than skb headroom.nsh_gso_segment nhoff = skb->network_header - skb->mac_header; __skb_pull(skb,nsh_len) skb_mac_gso_segment mpls_gso_segment skb_reset_network_header(skb);//skb->network_header+=nsh_len return -EINVAL; skb_gso_error_unwind skb_push(skb, nsh_len); skb->mac_header = skb->network_header - nhoff; // skb->mac_header > skb->headroom, cause skb_push panicUse correct mac_offset to restore mac_header and get rid of nhoff.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54121 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix incorrect splitting in btrfs_drop_extent_map_rangeIn production we were seeing a variety of WARN_ON()'s in the extent_mapcode, specifically in btrfs_drop_extent_map_range() when we have to calladd_extent_mapping() for our second split.Consider the following extent map layout PINNED [0 16K) [32K, 48K)and then we call btrfs_drop_extent_map_range for [0, 36K), withskip_pinned == true. The initial loop will have start = 0 end = 36K len = 36Kwe will find the [0, 16k) extent, but since we are pinned we will skipit, which has this code start = em_end; if (end != (u64)-1) len = start + len - em_end;em_end here is 16K, so now the values are start = 16K len = 16K + 36K - 16K = 36Klen should instead be 20K. This is a problem when we find the nextextent at [32K, 48K), we need to split this extent to leave [36K, 48k),however the code for the split looks like this split->start = start + len; split->len = em_end - (start + len);In this case we have em_end = 48K split->start = 16K + 36K // this should be 16K + 20K split->len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52Kand now we have an invalid extent_map in the tree that potentiallyoverlaps other entries in the extent map. Even in the non-overlappingcase we will have split->start set improperly, which will cause problemswith any block related calculations.We don't actually need len in this loop, we can simply use end as ourend point, and only adjust start up when we find a pinned extent we needto skip.Adjust the logic to do this, which keeps us from inserting an invalidextent map.We only skip_pinned in the relocation case, so this is relatively rare,except in the case where you are running relocation a lot, which canhappen with auto relocation on.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54124 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to drop all dirty pages during umount() if cp_error is setxfstest generic/361 reports a bug as below:f2fs_bug_on(sbi, sbi->fsync_node_num);kernel BUG at fs/f2fs/super.c:1627!RIP: 0010:f2fs_put_super+0x3a8/0x3b0Call Trace: generic_shutdown_super+0x8c/0x1b0 kill_block_super+0x2b/0x60 kill_f2fs_super+0x87/0x110 deactivate_locked_super+0x39/0x80 deactivate_super+0x46/0x50 cleanup_mnt+0x109/0x170 __cleanup_mnt+0x16/0x20 task_work_run+0x65/0xa0 exit_to_user_mode_prepare+0x175/0x190 syscall_exit_to_user_mode+0x25/0x50 do_syscall_64+0x4c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcDuring umount(), if cp_error is set, f2fs_wait_on_all_pages() shouldnot stop waiting all F2FS_WB_CP_DATA pages to be writebacked, otherwise,fsync_node_num can be non-zero after f2fs_wait_on_all_pages() causingthis bug.In this case, to avoid deadloop in f2fs_wait_on_all_pages(), it needsto drop all dirty pages rather than redirtying them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54129 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: Add validation for lmac typeUpon physical link change, firmware reports to the kernel about thechange along with the details like speed, lmac_type_id, etc.Kernel derives lmac_type based on lmac_type_id received from firmware.In a few scenarios, firmware returns an invalid lmac_type_id, whichis resulting in below kernel panic. This patch adds the missingvalidation of the lmac_type_id field.Internal error: Oops: 96000005 [#1] PREEMPT SMP[ 35.321595] Modules linked in:[ 35.328982] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted5.4.210-g2e3169d8e1bc-dirty #17[ 35.337014] Hardware name: Marvell CN103XX board (DT)[ 35.344297] Workqueue: events work_for_cpu_fn[ 35.352730] pstate: 40400089 (nZcv daIf +PAN -UAO)[ 35.360267] pc : strncpy+0x10/0x30[ 35.366595] lr : cgx_link_change_handler+0x90/0x180

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54132 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: stop parsing non-compact HEAD index if clusterofs is invalidSyzbot generated a crafted image [1] with a non-compact HEAD index ofclusterofs 33024 while valid numbers should be 0 ~ lclustersize-1,which causes the following unexpected behavior as below: BUG: unable to handle page fault for address: fffff52101a3fff9 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 23ffed067 P4D 23ffed067 PUD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 4398 Comm: kworker/u5:1 Not tainted 6.3.0-rc6-syzkaller-g09a9639e56c0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023 Workqueue: erofs_worker z_erofs_decompressqueue_work RIP: 0010:z_erofs_decompress_queue+0xb7e/0x2b40 ... Call Trace: z_erofs_decompressqueue_work+0x99/0xe0 process_one_work+0x8f6/0x1170 worker_thread+0xa63/0x1210 kthread+0x270/0x300 ret_from_fork+0x1f/0x30Note that normal images or images using compact indexes are notimpacted. Let's fix this now.[1] https://lore.kernel.org/r/000000000000ec75b005ee97fbaa@google.com

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54155 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: core: remove unnecessary frame_sz check in bpf_xdp_adjust_tail()Syzkaller reported the following issue:=======================================Too BIG xdp->frame_sz = 131072WARNING: CPU: 0 PID: 5020 at net/core/filter.c:4121 ____bpf_xdp_adjust_tail net/core/filter.c:4121 [inline]WARNING: CPU: 0 PID: 5020 at net/core/filter.c:4121 bpf_xdp_adjust_tail+0x466/0xa10 net/core/filter.c:4103...Call Trace: bpf_prog_4add87e5301a4105+0x1a/0x1c __bpf_prog_run include/linux/filter.h:600 [inline] bpf_prog_run_xdp include/linux/filter.h:775 [inline] bpf_prog_run_generic_xdp+0x57e/0x11e0 net/core/dev.c:4721 netif_receive_generic_xdp net/core/dev.c:4807 [inline] do_xdp_generic+0x35c/0x770 net/core/dev.c:4866 tun_get_user+0x2340/0x3ca0 drivers/net/tun.c:1919 tun_chr_write_iter+0xe8/0x210 drivers/net/tun.c:2043 call_write_iter include/linux/fs.h:1871 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x650/0xe40 fs/read_write.c:584 ksys_write+0x12f/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdxdp->frame_sz > PAGE_SIZE check was introduced in commit c8741e2bfe87("xdp: Allow bpf_xdp_adjust_tail() to grow packet size"). But JesperDangaard Brouer noted that after introducing thexdp_init_buff() which all XDP driver use - it's safe to remove thischeck. The original intend was to catch cases where XDP drivers havenot been updated to use xdp.frame_sz, but that is not longer a concern(since xdp_init_buff).Running the initial syzkaller repro it was discovered that thecontiguous physical memory allocation is used for both xdp paths intun_get_user(), e.g. tun_build_skb() and tun_alloc_skb(). It was alsostated by Jesper Dangaard Brouer that XDP canwork on higher order pages, as long as this is contiguous physicalmemory (e.g. a page).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54160 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_sdei: Fix sleep from invalid context BUGRunning a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altratriggers: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 24, name: cpuhp/0 preempt_count: 0, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by cpuhp/0/24: #0: ffffda30217c70d0 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #1: ffffda30217c7120 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #2: ffffda3021c711f0 (sdei_list_lock){....}-{3:3}, at: sdei_cpuhp_up+0x3c/0x130 irq event stamp: 36 hardirqs last enabled at (35): [] finish_task_switch+0xb4/0x2b0 hardirqs last disabled at (36): [] cpuhp_thread_fun+0x21c/0x248 softirqs last enabled at (0): [] copy_process+0x63c/0x1ac0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 0 PID: 24 Comm: cpuhp/0 Not tainted 5.19.0-rc3-rt5-[...] Hardware name: WIWYNN Mt.Jade Server [...] Call trace: dump_backtrace+0x114/0x120 show_stack+0x20/0x70 dump_stack_lvl+0x9c/0xd8 dump_stack+0x18/0x34 __might_resched+0x188/0x228 rt_spin_lock+0x70/0x120 sdei_cpuhp_up+0x3c/0x130 cpuhp_invoke_callback+0x250/0xf08 cpuhp_thread_fun+0x120/0x248 smpboot_thread_fn+0x280/0x320 kthread+0x130/0x140 ret_from_fork+0x10/0x20sdei_cpuhp_up() is called in the STARTING hotplug section,which runs with interrupts disabled. Use a CPUHP_AP_ONLINE_DYN entryinstead to execute the cpuhp cb later, with preemption enabled.SDEI originally got its own cpuhp slot to allow interactingwith perf. It got superseded by pNMI and this early slot is notrelevant anymore. [1]Some SDEI calls (e.g. SDEI_1_0_FN_SDEI_PE_MASK) take actions on thecalling CPU. It is checked that preemption is disabled for them._ONLINE cpuhp cb are executed in the 'per CPU hotplug thread'.Preemption is enabled in those threads, but their cpumask is limitedto 1 CPU.Move 'WARN_ON_ONCE(preemptible())' statements so that SDEI cpuhp cbdon't trigger them.Also add a check for the SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI callwhich acts on the calling CPU.[1]:https://lore.kernel.org/all/5813b8c5-ae3e-87fd-fccc-94c9cd08816d@arm.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54178 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:of: unittest: fix null pointer dereferencing in of_unittest_find_node_by_name()when kmalloc() fail to allocate memory in kasprintf(), nameor full_name will be NULL, strcmp() will causenull pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54181 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix issue in verifying allow_ptr_leaksAfter we converted the capabilities of our networking-bpf program fromcap_sys_admin to cap_net_admin+cap_bpf, our networking-bpf programfailed to start. Because it failed the bpf verifier, and the error logis "R3 pointer comparison prohibited".A simple reproducer as follows,SEC("cls-ingress")int ingress(struct __sk_buff *skb){ struct iphdr *iph = (void *)(long)skb->data + sizeof(struct ethhdr); if ((long)(iph + 1) > (long)skb->data_end) return TC_ACT_STOLEN; return TC_ACT_OK;}Per discussion with Yonghong and Alexei [1], comparison of two packetpointers is not a pointer leak. This patch fixes it.Our local kernel is 6.1.y and we expect this fix to be backported to6.1.y, so stable is CCed.[1]. https://lore.kernel.org/bpf/CAADnVQ+Nmspr7Si+pxWn8zkE7hX-7s93ugwC+94aXSy4uQ9vBg@mail.gmail.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54184 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsit: Free cmds before session freeCommands from recovery entries are freed after session has been closed.That leads to use-after-free at command free or NPE with such call trace:Time2Retain timer expired for SID: 1, cleaning up iSCSI session.BUG: kernel NULL pointer dereference, address: 0000000000000140RIP: 0010:sbitmap_queue_clear+0x3a/0xa0Call Trace: target_release_cmd_kref+0xd1/0x1f0 [target_core_mod] transport_generic_free_cmd+0xd1/0x180 [target_core_mod] iscsit_free_cmd+0x53/0xd0 [iscsi_target_mod] iscsit_free_connection_recovery_entries+0x29d/0x320 [iscsi_target_mod] iscsit_close_session+0x13a/0x140 [iscsi_target_mod] iscsit_check_post_dataout+0x440/0x440 [iscsi_target_mod] call_timer_fn+0x24/0x140Move cleanup of recovery enrties to before session freeing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54220 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250: Fix oops for port->pm on uart_change_pm()Unloading a hardware specific 8250 driver can produce error "Unable tohandle kernel paging request at virtual address" about ten seconds afterunloading the driver. This happens on uart_hangup() callinguart_change_pm().Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on portspecific driver unbind") was only a partial fix. If the hardware specificdriver has initialized port->pm function, we need to clear port->pm too.Just reinitializing port->ops does not do this. Otherwise serial8250_pm()will call port->pm() instead of serial8250_do_pm().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()There is a certain chance to trigger the following panic:PID: 5900 TASK: ffff88c1c8af4100 CPU: 1 COMMAND: "kworker/1:48" #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7 #1 [ffff9456c1cc79f0] __crash_kexec at ffffffff871b4c7a #2 [ffff9456c1cc7ab0] crash_kexec at ffffffff871b5b60 #3 [ffff9456c1cc7ac0] oops_end at ffffffff87026ce7 #4 [ffff9456c1cc7ae0] page_fault_oops at ffffffff87075715 #5 [ffff9456c1cc7b58] exc_page_fault at ffffffff87ad0654 #6 [ffff9456c1cc7b80] asm_exc_page_fault at ffffffff87c00b62 [exception RIP: ib_alloc_mr+19] RIP: ffffffffc0c9cce3 RSP: ffff9456c1cc7c38 RFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000004 RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88c1ea281d00 R8: 000000020a34ffff R9: ffff88c1350bbb20 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000010 R14: ffff88c1ab040a50 R15: ffff88c1ea281d00 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff9456c1cc7c60] smc_ib_get_memory_region at ffffffffc0aff6df [smc] #8 [ffff9456c1cc7c88] smcr_buf_map_link at ffffffffc0b0278c [smc] #9 [ffff9456c1cc7ce0] __smc_buf_create at ffffffffc0b03586 [smc]The reason here is that when the server tries to create a second link,smc_llc_srv_add_link() has no protection and may add a new link tolink group. This breaks the security environment protected byllc_conf_mutex.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54240 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: mtk_eth_soc: fix possible NULL pointer dereference in mtk_hwlro_get_fdir_all()rule_locs is allocated in ethtool_get_rxnfc and the size is determined byrule_cnt from user space. So rule_cnt needs to be check before usingrule_locs to avoid NULL pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54246 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcuscale: Move rcu_scale_writer() schedule_timeout_uninterruptible() to _idle()The rcuscale.holdoff module parameter can be used to delay the startof rcu_scale_writer() kthread. However, the hung-task timeout willtrigger when the timeout specified by rcuscale.holdoff is greater thanhung_task_timeout_secs:runqemu kvm nographic slirp qemuparams="-smp 4 -m 2048M"bootparams="rcuscale.shutdown=0 rcuscale.holdoff=300"[ 247.071753] INFO: task rcu_scale_write:59 blocked for more than 122 seconds.[ 247.072529] Not tainted 6.4.0-rc1-00134-gb9ed6de8d4ff #7[ 247.073400] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.[ 247.074331] task:rcu_scale_write state:D stack:30144 pid:59 ppid:2 flags:0x00004000[ 247.075346] Call Trace:[ 247.075660] [ 247.075965] __schedule+0x635/0x1280[ 247.076448] ? __pfx___schedule+0x10/0x10[ 247.076967] ? schedule_timeout+0x2dc/0x4d0[ 247.077471] ? __pfx_lock_release+0x10/0x10[ 247.078018] ? enqueue_timer+0xe2/0x220[ 247.078522] schedule+0x84/0x120[ 247.078957] schedule_timeout+0x2e1/0x4d0[ 247.079447] ? __pfx_schedule_timeout+0x10/0x10[ 247.080032] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.080591] ? __pfx_process_timeout+0x10/0x10[ 247.081163] ? __pfx_sched_set_fifo_low+0x10/0x10[ 247.081760] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.082287] rcu_scale_writer+0x6b1/0x7f0[ 247.082773] ? mark_held_locks+0x29/0xa0[ 247.083252] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.083865] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.084412] kthread+0x179/0x1c0[ 247.084759] ? __pfx_kthread+0x10/0x10[ 247.085098] ret_from_fork+0x2c/0x50[ 247.085433] This commit therefore replaces schedule_timeout_uninterruptible() withschedule_timeout_idle().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54251 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: taprio: Limit TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME to INT_MAX.syzkaller found zero division error [0] in div_s64_rem() called fromget_cycle_time_elapsed(), where sched->cycle_time is the divisor.We have tests in parse_taprio_schedule() so that cycle_time will neverbe 0, and actually cycle_time is not 0 in get_cycle_time_elapsed().The problem is that the types of divisor are different; cycle_time iss64, but the argument of div_s64_rem() is s32.syzkaller fed this input and 0x100000000 is cast to s32 to be 0. @TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME={0xc, 0x8, 0x100000000}We use s64 for cycle_time to cast it to ktime_t, so let's keep it andset max for cycle_time.While at it, we prevent overflow in setup_txtime() and add anothertest in parse_taprio_schedule() to check if cycle_time overflows.Also, we add a new tdc test case for this issue.[0]:divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 1 PID: 103 Comm: kworker/1:3 Not tainted 6.5.0-rc1-00330-g60cc1f7d0605 #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Workqueue: ipv6_addrconf addrconf_dad_workRIP: 0010:div_s64_rem include/linux/math64.h:42 [inline]RIP: 0010:get_cycle_time_elapsed net/sched/sch_taprio.c:223 [inline]RIP: 0010:find_entry_to_transmit+0x252/0x7e0 net/sched/sch_taprio.c:344Code: 3c 02 00 0f 85 5e 05 00 00 48 8b 4c 24 08 4d 8b bd 40 01 00 00 48 8b 7c 24 48 48 89 c8 4c 29 f8 48 63 f7 48 99 48 89 74 24 70 <48> f7 fe 48 29 d1 48 8d 04 0f 49 89 cc 48 89 44 24 20 49 8d 85 10RSP: 0018:ffffc90000acf260 EFLAGS: 00010206RAX: 177450e0347560cf RBX: 0000000000000000 RCX: 177450e0347560cfRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000100000000RBP: 0000000000000056 R08: 0000000000000000 R09: ffffed10020a0934R10: ffff8880105049a7 R11: ffff88806cf3a520 R12: ffff888010504800R13: ffff88800c00d800 R14: ffff8880105049a0 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff88806cf00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f0edf84f0e8 CR3: 000000000d73c002 CR4: 0000000000770ee0PKRU: 55555554Call Trace: get_packet_txtime net/sched/sch_taprio.c:508 [inline] taprio_enqueue_one+0x900/0xff0 net/sched/sch_taprio.c:577 taprio_enqueue+0x378/0xae0 net/sched/sch_taprio.c:658 dev_qdisc_enqueue+0x46/0x170 net/core/dev.c:3732 __dev_xmit_skb net/core/dev.c:3821 [inline] __dev_queue_xmit+0x1b2f/0x3000 net/core/dev.c:4169 dev_queue_xmit include/linux/netdevice.h:3088 [inline] neigh_resolve_output net/core/neighbour.c:1552 [inline] neigh_resolve_output+0x4a7/0x780 net/core/neighbour.c:1532 neigh_output include/net/neighbour.h:544 [inline] ip6_finish_output2+0x924/0x17d0 net/ipv6/ip6_output.c:135 __ip6_finish_output+0x620/0xaa0 net/ipv6/ip6_output.c:196 ip6_finish_output net/ipv6/ip6_output.c:207 [inline] NF_HOOK_COND include/linux/netfilter.h:292 [inline] ip6_output+0x206/0x410 net/ipv6/ip6_output.c:228 dst_output include/net/dst.h:458 [inline] NF_HOOK.constprop.0+0xea/0x260 include/linux/netfilter.h:303 ndisc_send_skb+0x872/0xe80 net/ipv6/ndisc.c:508 ndisc_send_ns+0xb5/0x130 net/ipv6/ndisc.c:666 addrconf_dad_work+0xc14/0x13f0 net/ipv6/addrconf.c:4175 process_one_work+0x92c/0x13a0 kernel/workqueue.c:2597 worker_thread+0x60f/0x1240 kernel/workqueue.c:2748 kthread+0x2fe/0x3f0 kernel/kthread.c:389 ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308 Modules linked in:

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54258 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix potential oops in cifs_oplock_breakWith deferred close we can have closes that race with lease breaks,and so with the current checks for whether to send the lease response,oplock_response(), this can mean that an unmount (kill_sb) can occurjust before we were checking if the tcon->ses is valid. See below:[Fri Aug 4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs][Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e <48> 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39[Fri Aug 4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206[Fri Aug 4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009[Fri Aug 4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188[Fri Aug 4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900[Fri Aug 4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138[Fri Aug 4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000[Fri Aug 4 04:12:50 2023] FS: 0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000[Fri Aug 4 04:12:50 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[Fri Aug 4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0[Fri Aug 4 04:12:50 2023] Call Trace:[Fri Aug 4 04:12:50 2023] [Fri Aug 4 04:12:50 2023] process_one_work+0x225/0x3d0[Fri Aug 4 04:12:50 2023] worker_thread+0x4d/0x3e0[Fri Aug 4 04:12:50 2023] ? process_one_work+0x3d0/0x3d0[Fri Aug 4 04:12:50 2023] kthread+0x12a/0x150[Fri Aug 4 04:12:50 2023] ? set_kthread_struct+0x50/0x50[Fri Aug 4 04:12:50 2023] ret_from_fork+0x22/0x30[Fri Aug 4 04:12:50 2023] To fix this change the ordering of the checks before sending the oplock_responseto first check if the openFileList is empty.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54263 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DPFixes OOPS on boards with ANX9805 DP encoders.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54281 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: release path before inode lookup during the ino lookup ioctlDuring the ino lookup ioctl we can end up calling btrfs_iget() to get aninode reference while we are holding on a root's btree. If btrfs_iget()needs to lookup the inode from the root's btree, because it's notcurrently loaded in memory, then it will need to lock another or thesame path in the same root btree. This may result in a deadlock andtrigger the following lockdep splat: WARNING: possible circular locking dependency detected 6.5.0-rc7-syzkaller-00004-gf7757129e3de #0 Not tainted ------------------------------------------------------ syz-executor277/5012 is trying to acquire lock: ffff88802df41710 (btrfs-tree-01){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 but task is already holding lock: ffff88802df418e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (btrfs-tree-00){++++}-{3:3}: down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645 __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 btrfs_search_slot+0x13a4/0x2f80 fs/btrfs/ctree.c:2302 btrfs_init_root_free_objectid+0x148/0x320 fs/btrfs/disk-io.c:4955 btrfs_init_fs_root fs/btrfs/disk-io.c:1128 [inline] btrfs_get_root_ref+0x5ae/0xae0 fs/btrfs/disk-io.c:1338 btrfs_get_fs_root fs/btrfs/disk-io.c:1390 [inline] open_ctree+0x29c8/0x3030 fs/btrfs/disk-io.c:3494 btrfs_fill_super+0x1c7/0x2f0 fs/btrfs/super.c:1154 btrfs_mount_root+0x7e0/0x910 fs/btrfs/super.c:1519 legacy_get_tree+0xef/0x190 fs/fs_context.c:611 vfs_get_tree+0x8c/0x270 fs/super.c:1519 fc_mount fs/namespace.c:1112 [inline] vfs_kern_mount+0xbc/0x150 fs/namespace.c:1142 btrfs_mount+0x39f/0xb50 fs/btrfs/super.c:1579 legacy_get_tree+0xef/0x190 fs/fs_context.c:611 vfs_get_tree+0x8c/0x270 fs/super.c:1519 do_new_mount+0x28f/0xae0 fs/namespace.c:3335 do_mount fs/namespace.c:3675 [inline] __do_sys_mount fs/namespace.c:3884 [inline] __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #0 (btrfs-tree-01){++++}-{3:3}: check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144 lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761 down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645 __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 btrfs_tree_read_lock fs/btrfs/locking.c:142 [inline] btrfs_read_lock_root_node+0x292/0x3c0 fs/btrfs/locking.c:281 btrfs_search_slot_get_root fs/btrfs/ctree.c:1832 [inline] btrfs_search_slot+0x4ff/0x2f80 fs/btrfs/ctree.c:2154 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:412 btrfs_read_locked_inode fs/btrfs/inode.c:3892 [inline] btrfs_iget_path+0x2d9/0x1520 fs/btrfs/inode.c:5716 btrfs_search_path_in_tree_user fs/btrfs/ioctl.c:1961 [inline] btrfs_ioctl_ino_lookup_user+0x77a/0xf50 fs/btrfs/ioctl.c:2105 btrfs_ioctl+0xb0b/0xd40 fs/btrfs/ioctl.c:4683 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0xf8/0x170 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd other info ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54306 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: tls: avoid hanging tasks on the tx_locksyzbot sent a hung task report and Eric explains that adversarialreceiver may keep RWIN at 0 for a long time, so we are not guaranteedto make forward progress. Thread which took tx_lock and went to sleepmay not release tx_lock for hours. Use interruptible sleep wherepossible and reschedule the work if it can't take the lock.Testing: existing selftest passes

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54318 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_addWhile doing smcr_port_add, there maybe linkgroup add into or deletefrom smc_lgr_list.list at the same time, which may result kernel crash.So, use smc_lgr_list.lock to protect smc_lgr_list.list iterate insmcr_port_add.The crash calltrace show below:BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: 0000 [#1] SMP NOPTICPU: 0 PID: 559726 Comm: kworker/0:92 Kdump: loaded Tainted: GHardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 449e491 04/01/2014Workqueue: events smc_ib_port_event_work [smc]RIP: 0010:smcr_port_add+0xa6/0xf0 [smc]RSP: 0000:ffffa5a2c8f67de0 EFLAGS: 00010297RAX: 0000000000000001 RBX: ffff9935e0650000 RCX: 0000000000000000RDX: 0000000000000010 RSI: ffff9935e0654290 RDI: ffff9935c8560000RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9934c0401918R10: 0000000000000000 R11: ffffffffb4a5c278 R12: ffff99364029aae4R13: ffff99364029aa00 R14: 00000000ffffffed R15: ffff99364029ab08FS: 0000000000000000(0000) GS:ffff994380600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 0000000f06a10003 CR4: 0000000002770ef0PKRU: 55555554Call Trace: smc_ib_port_event_work+0x18f/0x380 [smc] process_one_work+0x19b/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x114/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x1f/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2023-54323 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cxl/pmem: Fix nvdimm registration racesA loop of the form: while true; do modprobe cxl_pci; modprobe -r cxl_pci; done...fails with the following crash signature: BUG: kernel NULL pointer dereference, address: 0000000000000040 [..] RIP: 0010:cxl_internal_send_cmd+0x5/0xb0 [cxl_core] [..] Call Trace: cxl_pmem_ctl+0x121/0x240 [cxl_pmem] nvdimm_get_config_data+0xd6/0x1a0 [libnvdimm] nd_label_data_init+0x135/0x7e0 [libnvdimm] nvdimm_probe+0xd6/0x1c0 [libnvdimm] nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm] really_probe+0xde/0x380 __driver_probe_device+0x78/0x170 driver_probe_device+0x1f/0x90 __device_attach_driver+0x85/0x110 bus_for_each_drv+0x7d/0xc0 __device_attach+0xb4/0x1e0 bus_probe_device+0x9f/0xc0 device_add+0x445/0x9c0 nd_async_device_register+0xe/0x40 [libnvdimm] async_run_entry_fn+0x30/0x130...namely that the bottom half of async nvdimm device registration runsafter the CXL has already torn down the context that cxl_pmem_ctl()needs. Unlike the ACPI NFIT case that benefits from launching multiplenvdimm device registrations in parallel from those listed in the table,CXL is already marked PROBE_PREFER_ASYNCHRONOUS. So provide for asynchronous registration path to preclude this scenario.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-14027 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs/xattr: missing fdput() in fremovexattr error pathIn the Linux kernel, the fremovexattr() syscall calls fdget() to acquire afile reference but returns early without calling fdput() whenstrncpy_from_user() fails on the name argument. In multi-threaded processeswhere fdget() takes the slow path, this permanently leaks onefile reference per call, pinning the struct file and associated kernelobjects in memory. An unprivileged local user can exploit this to causekernel memory exhaustion. The issue was inadvertently fixed by commita71874379ec8 ("xattr: switch to CLASS(fd)").

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-2193 Severity: Moderate CVSS3 score: 5.5

Description: A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-22365 Severity: Moderate CVSS3 score: 5.5

Description: linux-pam (aka Linux PAM) before 1.6.0 allows attackers to cause a denial of service (blocked login process) via mkfifo because the openat call (for protect_dir) lacks O_DIRECTORY.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
pam > 0-0 (version in image is 1.3.0-150000.6.86.1).

CVE-2024-23337 Severity: Moderate CVSS3 score: 5.5

Description: jq is a command-line JSON processor. In versions up to and including 1.7.1, an integer overflow arises when assigning value using an index of 2147483647, the signed integer limit. This causes a denial of service. Commit de21386681c0df0104a99d9d09db23a9b2a78b1e contains a patch for the issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
jq > 0-0 (version in image is 1.6-150000.3.12.1).

CVE-2024-23849 Severity: Moderate CVSS3 score: 5.5

Description: In rds_recv_track_latency in net/rds/af_rds.c in the Linux kernel through 6.7.1, there is an off-by-one error for an RDS_MSG_RX_DGRAM_TRACE_MAX comparison, resulting in out-of-bounds access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-24860 Severity: Moderate CVSS3 score: 5.5

Description: A race condition was found in the Linux kernel's bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26615 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix illegal rmb_desc access in SMC-D connection dumpA crash was found when dumping SMC-D connections. It can be reproducedby following steps:- run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d -H 'Connection: Close' - continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D' BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? asm_exc_page_fault+0x26/0x30 ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] ? __kmalloc_node_track_caller+0x35d/0x430 ? __alloc_skb+0x77/0x170 smc_diag_dump_proto+0xd0/0xf0 [smc_diag] smc_diag_dump+0x26/0x60 [smc_diag] netlink_dump+0x19f/0x320 __netlink_dump_start+0x1dc/0x300 smc_diag_handler_dump+0x6a/0x80 [smc_diag] ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag] sock_diag_rcv_msg+0x121/0x140 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x5a/0x110 sock_diag_rcv+0x28/0x40 netlink_unicast+0x22a/0x330 netlink_sendmsg+0x1f8/0x420 __sock_sendmsg+0xb0/0xc0 ____sys_sendmsg+0x24e/0x300 ? copy_msghdr_from_user+0x62/0x80 ___sys_sendmsg+0x7c/0xd0 ? __do_fault+0x34/0x160 ? do_read_fault+0x5f/0x100 ? do_fault+0xb0/0x110 ? __handle_mm_fault+0x2b0/0x6c0 __sys_sendmsg+0x4d/0x80 do_syscall_64+0x69/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76It is possible that the connection is in process of being establishedwhen we dump it. Assumed that the connection has been registered in alink group by smc_conn_create() but the rmb_desc has not yet beeninitialized by smc_buf_create(), thus causing the illegal access toconn->rmb_desc. So fix it by checking before dump.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26625 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:llc: call sock_orphan() at release timesyzbot reported an interesting trace [1] caused by a stale sk->sk_wqpointer in a closed llc socket.In commit ff7b11aa481f ("net: socket: set sock->sk to NULL aftercalling proto_ops::release()") Eric Biggers hinted that some protocolsare missing a sock_orphan(), we need to perform a full audit.In net-next, I plan to clear sock->sk from sock_orphan() andamend Eric patch to add a warning.[1] BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline] BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline] BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline] BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/list.h:373 [inline] waitqueue_active include/linux/wait.h:127 [inline] sock_def_write_space_wfree net/core/sock.c:3384 [inline] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [inline] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline] e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801 __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x956/0xe90 net/core/dev.c:6778 __do_softirq+0x21a/0x8de kernel/softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Allocated by task 5167: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3019 [inline] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net/socket.c:634 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x14c/0x260 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bFreed by task 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inlin---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26627 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Move scsi_host_busy() out of host lock for waking up EH handlerInside scsi_eh_wakeup(), scsi_host_busy() is called & checked with hostlock every time for deciding if error handler kthread needs to be waken up.This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requestsIf recovery is triggered in case that all requests are in-flight, eachscsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is calledfor the last in-flight request, scsi_host_busy() has been run for (N * M -1) times, and request has been iterated for (N*M - 1) * (N * M) times.If both N and M are big enough, hard lockup can be triggered on acquiringhost lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169).Fix the issue by calling scsi_host_busy() outside the host lock. We don'tneed the host lock for getting busy count because host the lock nevercovers that.[mkp: Drop unnecessary 'busy' variables pointed out by Bart]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26631 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_workidev->mc_ifc_count can be written over without proper locking.Originally found by syzbot [1], fix this issue by encapsulating callsto mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) withmutex_lock() and mutex_unlock() accordingly as these functionsshould only be called with mc_lock per their declarations.[1]BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_workwrite to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ...write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26636 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:llc: make llc_ui_sendmsg() more robust against bonding changessyzbot was able to trick llc_ui_sendmsg(), allocating an skb with noheadroom, but subsequently trying to push 14 bytes of Ethernet header [1]Like some others, llc_ui_sendmsg() releases the socket lock beforecalling sock_alloc_send_skb().Then it acquires it again, but does not redo all the sanity checksthat were performed.This fix:- Uses LL_RESERVED_SPACE() to reserve space.- Check all conditions again after socket lock is held again.- Do not account Ethernet header for mtu limitation.[1]skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 kernel BUG at net/core/skbuff.c:193 !Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMPModules linked in:CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203sp : ffff800096f97000x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261cex17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26640 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: add sanity checks to rx zerocopyTCP rx zerocopy intent is to map pages initially allocatedfrom NIC drivers, not pages owned by a fs.This patch adds to can_map_frag() these additional checks:- Page must not be a compound one.- page->mapping must be NULL.This fixes the panic reported by ZhangPeng.syzbot was able to loopback packets built with sendfile(),mapping pages owned by an ext4 file to TCP rx zerocopy.r3 = socket$inet_tcp(0x2, 0x1, 0x0)mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)r4 = socket$inet_tcp(0x2, 0x1, 0x0)bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0)fallocate(r5, 0x0, 0x0, 0x85b8)sendfile(r4, r5, 0x0, 0x8ba0)getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40)r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26645 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Ensure visibility when inserting an element into tracing_mapRunning the following two commands in parallel on a multi-processorAArch64 machine can sporadically produce an unexpected warning aboutduplicate histogram entries: $ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc)The warning looks as follows:[ 2911.172474] ------------[ cut here ]------------[ 2911.173111] Duplicates detected: 1[ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408[ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)[ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1[ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01[ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018[ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)[ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408[ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408[ 2911.185310] sp : ffff8000a1513900[ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001[ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008[ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180[ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff[ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8[ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731[ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c[ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8[ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000[ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480[ 2911.194259] Call trace:[ 2911.194626] tracing_map_sort_entries+0x3e0/0x408[ 2911.195220] hist_show+0x124/0x800[ 2911.195692] seq_read_iter+0x1d4/0x4e8[ 2911.196193] seq_read+0xe8/0x138[ 2911.196638] vfs_read+0xc8/0x300[ 2911.197078] ksys_read+0x70/0x108[ 2911.197534] __arm64_sys_read+0x24/0x38[ 2911.198046] invoke_syscall+0x78/0x108[ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8[ 2911.199157] do_el0_svc+0x28/0x40[ 2911.199613] el0_svc+0x40/0x178[ 2911.200048] el0t_64_sync_handler+0x13c/0x158[ 2911.200621] el0t_64_sync+0x1a8/0x1b0[ 2911.201115] ---[ end trace 0000000000000000 ]---The problem appears to be caused by CPU reordering of writes issued from__tracing_map_insert().The check for the presence of an element with a given key in thisfunction is: val = READ_ONCE(entry->val); if (val && keys_match(key, val->key, map->key_size)) ...The write of a new entry is: elt = get_free_elt(map); memcpy(elt->key, key, map->key_size); entry->val = elt;The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;"stores may become visible in the reversed order on another CPU. Thissecond CPU might then incorrectly determine that a new key doesn't matchan already present val->key and subse---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26659 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xhci: handle isoc Babble and Buffer Overrun events properlyxHCI 4.9 explicitly forbids assuming that the xHC has released itsownership of a multi-TRB TD when it reports an error on one of theearly TRBs. Yet the driver makes such assumption and releases the TD,allowing the remaining TRBs to be freed or overwritten by new TDs.The xHC should also report completion of the final TRB due to its IOCflag being set by us, regardless of prior errors. This event cannotbe recognized if the TD has already been freed earlier, resulting in"Transfer event TRB DMA ptr not part of current TD" error message.Fix this by reusing the logic for processing isoc Transaction Errors.This also handles hosts which fail to report the final completion.Fix transfer length reporting on Babble errors. They may be caused bydevice malfunction, no guarantee that the buffer has been filled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26660 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Implement bounds check for stream encoder creation in DCN301'stream_enc_regs' array is an array of dcn10_stream_enc_registersstructures. The array is initialized with four elements, correspondingto the four calls to stream_enc_regs() in the array initializer. Thismeans that valid indices for this array are 0, 1, 2, and 3.The error message 'stream_enc_regs' 4 <= 5 below, is indicating thatthere is an attempt to access this array with an index of 5, which isout of bounds. This could lead to undefined behaviorHere, eng_id is used as an index to access the stream_enc_regs array. Ifeng_id is 5, this would result in an out-of-bounds access on thestream_enc_regs array.Thus fixing Buffer overflow error in dcn301_stream_encoder_createreported by Smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26662 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()''panel_cntl' structure used to control the display panel could be null,dereferencing it could lead to a null pointer access.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 dcn21_set_backlight_level() error: we previously assumed 'panel_cntl' could be null (see line 250)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26664 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (coretemp) Fix out-of-bounds memory accessFix a bug that pdata->cpu_map[] is set before out-of-bounds check.The problem might be triggered on systems with more than 128 cores perpackage.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26669 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: flower: Fix chain template offloadWhen a qdisc is deleted from a net device the stack instructs theunderlying driver to remove its flow offload callback from theassociated filter block using the 'FLOW_BLOCK_UNBIND' command. The stackthen continues to replay the removal of the filters in the block forthis driver by iterating over the chains in the block and invoking the'reoffload' operation of the classifier being used. In turn, theclassifier in its 'reoffload' operation prepares and emits a'FLOW_CLS_DESTROY' command for each filter.However, the stack does not do the same for chain templates and theunderlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command whena qdisc is deleted. This results in a memory leak [1] which can bereproduced using [2].Fix by introducing a 'tmplt_reoffload' operation and have the stackinvoke it with the appropriate arguments as part of the replay.Implement the operation in the sole classifier that supports chaintemplates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}'command based on whether a flow offload callback is being bound to afilter block or being unbound from one.As far as I can tell, the issue happens since cited commit whichreordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()in __tcf_block_put(). The order cannot be reversed as the filter blockis expected to be freed after flushing all the chains.[1]unreferenced object 0xffff888107e28800 (size 2048): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[...... 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................ backtrace: [] __kmem_cache_alloc_node+0x1e8/0x320 [] __kmalloc+0x4e/0x90 [] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0 [] mlxsw_sp_flower_tmplt_create+0x145/0x180 [] mlxsw_sp_flow_block_cb+0x1ea/0x280 [] tc_setup_cb_call+0x183/0x340 [] fl_tmplt_create+0x3da/0x4c0 [] tc_ctl_chain+0xa15/0x1170 [] rtnetlink_rcv_msg+0x3cc/0xed0 [] netlink_rcv_skb+0x170/0x440 [] netlink_unicast+0x540/0x820 [] netlink_sendmsg+0x8d8/0xda0 [] ____sys_sendmsg+0x30f/0xa80 [] ___sys_sendmsg+0x13a/0x1e0 [] __sys_sendmsg+0x11c/0x1f0 [] do_syscall_64+0x40/0xe0unreferenced object 0xffff88816d2c0400 (size 1024): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8..... 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m.... backtrace: [] __kmem_cache_alloc_node+0x1e8/0x320 [] __kmalloc_node+0x51/0x90 [] kvmalloc_node+0xa6/0x1f0 [] bucket_table_alloc.isra.0+0x83/0x460 [] rhashtable_init+0x43b/0x7c0 [] mlxsw_sp_acl_ruleset_get+0x428/0x7a0 [] mlxsw_sp_flower_tmplt_create+0x145/0x180 [] mlxsw_sp_flow_block_cb+0x1ea/0x280 [] tc_setup_cb_call+0x183/0x340 [] fl_tmplt_create+0x3da/0x4c0 [] tc_ctl_chain+0xa15/0x1170 [] rtnetlink_rcv_msg+0x3cc/0xed0 [] netlink_rcv_skb+0x170/0x440 [] netlink_unicast+0x540/0x820 [] netlink_sendmsg+0x8d8/0xda0 [] ____sys_sendmsg+0x30f/0xa80[2] # tc qdisc add dev swp1 clsact # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32 # tc qdisc del dev---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26671 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix IO hang from sbitmap wakeup raceIn blk_mq_mark_tag_wait(), __add_wait_queue() may be re-orderedwith the following blk_mq_get_driver_tag() in case of getting drivertag failure.Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observethe added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantimeblk_mq_mark_tag_wait() can't get driver tag successfully.This issue can be reproduced by running the following test in loop, andfio hang can be observed in < 30min when running it on my test VMin laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100 --numjobs=40 --time_based --name=test \ --ioengine=libaioFix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), whichis just fine in case of running out of tag.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26673 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.- Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26675 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ppp_async: limit MRU to 64Ksyzbot triggered a warning [1] in __alloc_pages():WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K")Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)[1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543Modules linked in:CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023Workqueue: events_unbound flush_to_ldiscpstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537sp : ffff800093967580x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003fx5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26680 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: atlantic: Fix DMA mapping for PTP hwts ringFunction aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytesfor PTP HWTS ring but then generic aq_ring_free() does not take thisinto account.Create and use a specific function to free HWTS ring to fix thisissue.Trace:[ 215.351607] ------------[ cut here ]------------[ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes][ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360...[ 215.581176] Call Trace:[ 215.583632] [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df[ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df[ 215.594497] ? debug_dma_free_coherent+0x196/0x210[ 215.599305] ? check_unmap+0xa6f/0x2360[ 215.603147] ? __warn+0xca/0x1d0[ 215.606391] ? check_unmap+0xa6f/0x2360[ 215.610237] ? report_bug+0x1ef/0x370[ 215.613921] ? handle_bug+0x3c/0x70[ 215.617423] ? exc_invalid_op+0x14/0x50[ 215.621269] ? asm_exc_invalid_op+0x16/0x20[ 215.625480] ? check_unmap+0xa6f/0x2360[ 215.629331] ? mark_lock.part.0+0xca/0xa40[ 215.633445] debug_dma_free_coherent+0x196/0x210[ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10[ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0[ 215.648060] dma_free_attrs+0x6d/0x130[ 215.651834] aq_ring_free+0x193/0x290 [atlantic][ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic]...[ 216.127540] ---[ end trace 6467e5964dd2640b ]---[ 216.132160] DMA-API: Mapped at:[ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0[ 216.132165] dma_alloc_attrs+0xf5/0x1b0[ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic][ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic][ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26684 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: xgmac: fix handling of DPP safety error for DMA channelsCommit 56e58d6c8a56 ("net: stmmac: Implement Safety Features inXGMAC core") checks and reports safety errors, but leaves theData Path Parity Errors for each channel in DMA unhandled at all, lead toa storm of interrupt.Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26685 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix potential bug in end_buffer_async_writeAccording to a syzbot report, end_buffer_async_write(), which handles thecompletion of block device writes, may detect abnormal condition of thebuffer async_write flag and cause a BUG_ON failure when using nilfs2.Nilfs2 itself does not use end_buffer_async_write(). But, the async_writeflag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issuewith race condition of competition between segments for dirty blocks") asa means of resolving double list insertion of dirty blocks innilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and theresulting crash.This modification is safe as long as it is used for file data and b-treenode blocks where the page caches are independent. However, it wasirrelevant and redundant to also introduce async_write for segment summaryand super root blocks that share buffers with the backing device. Thisled to the possibility that the BUG_ON check in end_buffer_async_writewould fail as described above, if independent writebacks of the backingdevice occurred in parallel.The use of async_write for segment summary buffers has already beenremoved in a previous change.Fix this issue by removing the manipulation of the async_write flag forthe remaining super root block buffer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26695 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_lockedThe SEV platform device can be shutdown with a null psp_master,e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN:[ 137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002)[ 137.162647] ccp 0000:23:00.1: no command queues available[ 137.170598] ccp 0000:23:00.1: sev enabled[ 137.174645] ccp 0000:23:00.1: psp enabled[ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI[ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7][ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311[ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180[ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c[ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216[ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e[ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0[ 137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66[ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28[ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8[ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000[ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0[ 137.182693] Call Trace:[ 137.182693] [ 137.182693] ? show_regs+0x6c/0x80[ 137.182693] ? __die_body+0x24/0x70[ 137.182693] ? die_addr+0x4b/0x80[ 137.182693] ? exc_general_protection+0x126/0x230[ 137.182693] ? asm_exc_general_protection+0x2b/0x30[ 137.182693] ? __sev_platform_shutdown_locked+0x51/0x180[ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80[ 137.182693] sev_dev_destroy+0x49/0x100[ 137.182693] psp_dev_destroy+0x47/0xb0[ 137.182693] sp_destroy+0xbb/0x240[ 137.182693] sp_pci_remove+0x45/0x60[ 137.182693] pci_device_remove+0xaa/0x1d0[ 137.182693] device_remove+0xc7/0x170[ 137.182693] really_probe+0x374/0xbe0[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] __driver_probe_device+0x199/0x460[ 137.182693] driver_probe_device+0x4e/0xd0[ 137.182693] __driver_attach+0x191/0x3d0[ 137.182693] ? __pfx___driver_attach+0x10/0x10[ 137.182693] bus_for_each_dev+0x100/0x190[ 137.182693] ? __pfx_bus_for_each_dev+0x10/0x10[ 137.182693] ? __kasan_check_read+0x15/0x20[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] ? _raw_spin_unlock+0x27/0x50[ 137.182693] driver_attach+0x41/0x60[ 137.182693] bus_add_driver+0x2a8/0x580[ 137.182693] driver_register+0x141/0x480[ 137.182693] __pci_register_driver+0x1d6/0x2a0[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] ? esrt_sysfs_init+0x1cd/0x5d0[ 137.182693] ? __pfx_sp_mod_init+0x10/0x10[ 137.182693] sp_pci_init+0x22/0x30[ 137.182693] sp_mod_init+0x14/0x30[ 137.182693] ? __pfx_sp_mod_init+0x10/0x10[ 137.182693] do_one_initcall+0xd1/0x470[ 137.182693] ? __pfx_do_one_initcall+0x10/0x10[ 137.182693] ? parameq+0x80/0xf0[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] ? __kmalloc+0x3b0/0x4e0[ 137.182693] ? kernel_init_freeable+0x92d/0x1050[ 137.182693] ? kasan_populate_vmalloc_pte+0x171/0x190[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] kernel_init_freeable+0xa64/0x1050[ 137.182693] ? __pfx_kernel_init+0x10/0x10[ 137.182693] kernel_init+0x24/0x160[ 137.182693] ? __switch_to_asm+0x3e/0x70[ 137.182693] ret_from_fork+0x40/0x80[ 137.182693] ? __pfx_kernel_init+0x1---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26696 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()Syzbot reported a hang issue in migrate_pages_batch() called by mbind()and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.While migrate_pages_batch() locks a folio and waits for the writeback tocomplete, the log writer thread that should bring the writeback tocompletion picks up the folio being written back innilfs_lookup_dirty_data_buffers() that it calls for subsequent logcreation and was trying to lock the folio. Thus causing a deadlock.In the first place, it is unexpected that folios/pages in the middle ofwriteback will be updated and become dirty. Nilfs2 adds a checksum toverify the validity of the log being written and uses it for recovery atmount, so data changes during writeback are suppressed. Since this isbroken, an unclean shutdown could potentially cause recovery to fail.Investigation revealed that the root cause is that the wait for writebackcompletion in nilfs_page_mkwrite() is conditional, and if the backingdevice does not require stable writes, data may be modified withoutwaiting.Fix these issues by making nilfs_page_mkwrite() wait for writeback tofinish regardless of the stable write requirement of the backing device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26698 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hv_netvsc: Fix race condition between netvsc_probe and netvsc_removeIn commit ac5047671758 ("hv_netvsc: Disable NAPI before closing theVMBus channel"), napi_disable was getting called for all channels,including all subchannels without confirming if they are enabled or not.This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()has finished running but nvdev->subchan_work has not started yet.netvsc_subchan_work() -> rndis_set_subchannel() has not created thesub-channels and because of that netvsc_sc_open() is not running.netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for whichnetvsc_subchan_work did not run.netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPIcannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear theNAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does theopposite.Now during netvsc_device_remove(), when napi_disable is called for thosesubchannels, napi_disable gets stuck on infinite msleep.This fix addresses this problem by ensuring that napi_disable() is notgetting called for non-enabled NAPI struct.But netif_napi_del() is still necessary for these non-enabled NAPI structfor cleanup purpose.Call trace:[ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002[ 654.568030] Call Trace:[ 654.571221] [ 654.573790] __schedule+0x2d6/0x960[ 654.577733] schedule+0x69/0xf0[ 654.581214] schedule_timeout+0x87/0x140[ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20[ 654.590291] msleep+0x2d/0x40[ 654.593625] napi_disable+0x2b/0x80[ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc][ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc][ 654.611101] ? do_wait_intr+0xb0/0xb0[ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc][ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26702 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRCRecently, we encounter kernel crash in function rm3100_common_probecaused by out of bound access of array rm3100_samp_rates (because ofunderlying hardware failures). Add boundary check to prevent out ofbound access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26707 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()Syzkaller reported [1] hitting a warning after failing to allocateresources for skb in hsr_init_skb(). Since a WARN_ONCE() call willnot help much in this case, it might be prudent to switch tonetdev_warn_once(). At the very least it will suppress syzkallerreports such as [1].Just in case, use netdev_warn_once() in send_prp_supervision_frame()for similar reasons.[1]HSR: Could not send supervision frameWARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294...Call Trace: hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1751 [inline] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649...This issue is also found in older kernels (at least up to 5.10).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26717 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: i2c-hid-of: fix NULL-deref on failed power upA while back the I2C HID implementation was split in an ACPI and OFpart, but the new OF driver never initialises the client pointer whichis dereferenced on power-up failures.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26718 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm-crypt, dm-verity: disable taskletsTasklets have an inherent problem with memory corruption. The functiontasklet_action_common calls tasklet_trylock, then it calls the taskletcallback and then it calls tasklet_unlock. If the tasklet callback freesthe structure that contains the tasklet or if it calls some code that mayfree it, tasklet_unlock will write into free memory.The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, butit is not a sufficient fix and the data corruption can still happen [1].There is no fix for dm-verity and dm-verity will write into free memorywith every tasklet-processed bio.There will be atomic workqueues implemented in the kernel 6.9 [2]. Theywill have better interface and they will not suffer from the memorycorruption problem.But we need something that stops the memory corruption now and that can bebackported to the stable kernels. So, I'm proposing this commit thatdisables tasklets in both dm-crypt and dm-verity. This commit doesn'tremove the tasklet support, because the tasklet code will be reused whenatomic workqueues will be implemented.[1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/[2] https://lore.kernel.org/lkml/20240130091300.2968534-1-tj@kernel.org/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26735 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix possible use-after-free and null-ptr-derefThe pernet operations structure for the subsystem must be registeredbefore registering the generic netlink family.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26742 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Fix disable_managed_interruptsCorrect blk-mq registration issue with module parameterdisable_managed_interrupts enabled.When we turn off the default PCI_IRQ_AFFINITY flag, the driver needs toregister with blk-mq using blk_mq_map_queues(). The driver is currentlycalling blk_mq_pci_map_queues() which results in a stack trace and possiblyundefined behavior.Stack Trace:[ 7.860089] scsi host2: smartpqi[ 7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0[ 7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse[ 7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1[ 7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022[ 7.963026] Workqueue: events work_for_cpu_fn[ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0[ 7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54[ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216[ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010[ 7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310[ 7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00[ 7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000[ 7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8[ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000[ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0[ 8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 8.172818] PKRU: 55555554[ 8.172819] Call Trace:[ 8.172823] blk_mq_alloc_tag_set+0x12e/0x310[ 8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245[ 8.279302] pqi_ctrl_init+0xacf/0xc8e [smartpqi][ 8.294085] ? pqi_pci_probe+0x480/0x4c8 [smartpqi][ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi][ 8.323286] local_pci_probe+0x42/0x80[ 8.337855] work_for_cpu_fn+0x16/0x20[ 8.351193] process_one_work+0x1a7/0x360[ 8.364462] ? create_worker+0x1a0/0x1a0[ 8.379252] worker_thread+0x1ce/0x390[ 8.392623] ? create_worker+0x1a0/0x1a0[ 8.406295] kthread+0x10a/0x120[ 8.418428] ? set_kthread_struct+0x50/0x50[ 8.431532] ret_from_fork+0x1f/0x40[ 8.444137] ---[ end trace 1bf0173d39354506 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26744 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/srpt: Support specifying the srpt_service_guid parameterMake loading ib_srpt with this parameter set work. The current behavior isthat setting that parameter while loading the ib_srpt kernel moduletriggers the following kernel crash:BUG: kernel NULL pointer dereference, address: 0000000000000000Call Trace: parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 entry_SYSCALL_64_after_hwframe+0x6e/0x76

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26748 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: fix memory double free when handle zero packet829 if (request->complete) {830 spin_unlock(&priv_dev->lock);831 usb_gadget_giveback_request(&priv_ep->endpoint,832 request);833 spin_lock(&priv_dev->lock);834 }835836 if (request->buf == priv_dev->zlp_buf)837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request);Driver append an additional zero packet request when queue a packet, whichlength mod max packet size is 0. When transfer complete, run to line 831,usb_gadget_giveback_request() will free this requestion. 836 condition istrue, so cdns3_gadget_ep_free_request() free this request again.Log:[ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3][ 1920.140696][ T150][ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):[ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3][ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]Add check at line 829, skip call usb_gadget_giveback_request() if it isadditional zero length packet request. Needn't callusb_gadget_giveback_request() because it is allocated in this driver.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26754 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()The gtp_net_ops pernet operations structure for the subsystem must beregistered before registering the generic netlink family.Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:general protection fault, probably for non-canonical address0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74RSP: 0018:ffff888014107220 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0PKRU: 55555554Call Trace: ? show_regs+0x90/0xa0 ? die_addr+0x50/0xd0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ? gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfx___alloc_skb+0x10/0x10 genl_dumpit+0x11d/0x230 netlink_dump+0x5b9/0xce0 ? lockdep_hardirqs_on_prepare+0x253/0x430 ? __pfx_netlink_dump+0x10/0x10 ? kasan_save_track+0x10/0x40 ? __kasan_kmalloc+0x9b/0xa0 ? genl_start+0x675/0x970 __netlink_dump_start+0x6fc/0x9f0 genl_family_rcv_msg_dumpit+0x1bb/0x2d0 ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10 ? genl_op_from_small+0x2a/0x440 ? cap_capable+0x1d0/0x240 ? __pfx_genl_start+0x10/0x10 ? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 ? security_capable+0x9d/0xe0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26763 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm-crypt: don't modify the data when using authenticated encryptionIt was said that authenticated encryption could produce invalid tag whenthe data that is being encrypted is modified [1]. So, fix this problem bycopying the data into the clone bio first and then encrypt them inside theclone bio.This may reduce performance, but it is needed to prevent the user fromcorrupting the device by writing data with O_DIRECT and modifying them atthe same time.[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26771 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: edma: Add some null pointer checks to the edma_probedevm_kasprintf() returns a pointer to dynamically allocated memorywhich can be NULL upon failure. Ensure the allocation was successfulby checking the pointer validity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26772 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()Places the logic for checking if the group's block bitmap is corrupt underthe protection of the group lock to avoid allocating blocks from the groupwith a corrupted block bitmap.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26775 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:aoe: avoid potential deadlock at set_capacityMove set_capacity() outside of the section procected by (&d->lock).To avoid possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ----[1] lock(&bdev->bd_size_lock); local_irq_disable(); [2] lock(&d->lock); [3] lock(&bdev->bd_size_lock); [4] lock(&d->lock); *** DEADLOCK ***Where [1](&bdev->bd_size_lock) hold by zram_add()->set_capacity().[2]lock(&d->lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc()is trying to acquire [3](&bdev->bd_size_lock) at set_capacity() call.In this situation an attempt to acquire [4]lock(&d->lock) fromaoecmd_cfg_rsp() will lead to deadlock.So the simplest solution is breaking lock dependency[2](&d->lock) -> [3](&bdev->bd_size_lock) by moving set_capacity()outside.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26776 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detectedReturn IRQ_NONE from the interrupt handler when no interrupt wasdetected. Because an empty interrupt will cause a null pointer error: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: complete+0x54/0x100 hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx] __handle_irq_event_percpu+0x64/0x1e0 handle_irq_event+0x7c/0x1cc

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26777 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: sis: Error out if pixclock equals zeroThe userspace program could pass any values to the driver throughioctl() interface. If the driver doesn't check the value of pixclock,it may cause divide-by-zero error.In sisfb_check_var(), var->pixclock is used as a divisor to caculatedrate before it is checked against zero. Fix this by checking itat the beginning.This is similar to CVE-2022-3061 in i740fb which was fixed bycommit 15cf0b8.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26779 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix race condition on enabling fast-xmitfast-xmit must only be enabled after the sta has been uploaded to the driver,otherwise it could end up passing the not-yet-uploaded sta via drv_tx callsto the driver, leading to potential crashes because of uninitialized drv_privdata.Add a missing sta->uploaded check and re-check fast xmit after inserting a sta.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mmc: mmci: stm32: fix DMA API overlapping mappings warningTurning on CONFIG_DMA_API_DEBUG_SG results in the following warning:DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,overlapping mappings aren't supportedWARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568add_dma_entry+0x234/0x2f4Modules linked in:CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)Workqueue: events_freezable mmc_rescanCall trace:add_dma_entry+0x234/0x2f4debug_dma_map_sg+0x198/0x350__dma_map_sg_attrs+0xa0/0x110dma_map_sg_attrs+0x10/0x2csdmmc_idma_prep_data+0x80/0xc0mmci_prep_data+0x38/0x84mmci_start_data+0x108/0x2dcmmci_request+0xe4/0x190__mmc_start_request+0x68/0x140mmc_start_request+0x94/0xc0mmc_wait_for_req+0x70/0x100mmc_send_tuning+0x108/0x1acsdmmc_execute_tuning+0x14c/0x210mmc_execute_tuning+0x48/0xecmmc_sd_init_uhs_card.part.0+0x208/0x464mmc_sd_init_card+0x318/0x89cmmc_attach_sd+0xe4/0x180mmc_rescan+0x244/0x320DMA API debug brings to light leaking dma-mappings as dma_map_sg anddma_unmap_sg are not correctly balanced.If an error occurs in mmci_cmd_irq function, only mmci_dma_errorfunction is called and as this API is not managed on stm32 variant,dma_unmap_sg is never called in this error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26788 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: fsl-qdma: init irq after reg initializationInitialize the qDMA irqs after the registers are configured so thatinterrupts that may have been pending from a primary kernel don't getprocessed by the irq handler before it is ready to and cause panic withthe following trace: Call trace: fsl_qdma_queue_handler+0xf8/0x3e8 __handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi_irq+0xc8/0x178 generic_handle_irq+0x24/0x38 __handle_domain_irq+0x90/0x100 gic_handle_irq+0x5c/0xb8 el1_irq+0xb8/0x180 _raw_spin_unlock_irqrestore+0x14/0x40 __setup_irq+0x4bc/0x798 request_threaded_irq+0xd8/0x190 devm_request_threaded_irq+0x74/0xe8 fsl_qdma_probe+0x4d4/0xca8 platform_drv_probe+0x50/0xa0 really_probe+0xe0/0x3f8 driver_probe_device+0x64/0x130 device_driver_attach+0x6c/0x78 __driver_attach+0xbc/0x158 bus_for_each_dev+0x5c/0x98 driver_attach+0x20/0x28 bus_add_driver+0x158/0x220 driver_register+0x60/0x110 __platform_driver_register+0x44/0x50 fsl_qdma_driver_init+0x18/0x20 do_one_initcall+0x48/0x258 kernel_init_freeable+0x1a4/0x23c kernel_init+0x10/0xf8 ret_from_fork+0x10/0x18

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26790 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned readThere is chip (ls1028a) errata:The SoC may hang on 16 byte unaligned read transactions by QDMA.Unaligned read transactions initiated by QDMA may stall in the NOC(Network On-Chip), causing a deadlock condition. Stalled transactions willtrigger completion timeouts in PCIe controller.Workaround:Enable prefetch by setting the source descriptor prefetchable bit( SD[PF] = 1 ).Implement this workaround.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26791 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: dev-replace: properly validate device namesThere's a syzbot report that device name buffers passed to devicereplace are not properly checked for string termination which could leadto a read out of bounds in getname_kernel().Add a helper that validates both source and target device name buffers.For devid as the source initialize the buffer to empty string in casesomething tries to read it later.This was originally analyzed and fixed in a different way by Edward AdamDavis (see links).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26793 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: fix use-after-free and null-ptr-deref in gtp_newlink()The gtp_link_ops operations structure for the subsystem must beregistered after registering the gtp_net_ops pernet operations structure.Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:[ 1010.702740] gtp: GTP module unloaded[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f][ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp][ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400[ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000[ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0[ 1010.715968] PKRU: 55555554[ 1010.715972] Call Trace:[ 1010.715985] ? __die_body.cold+0x1a/0x1f[ 1010.715995] ? die_addr+0x43/0x70[ 1010.716002] ? exc_general_protection+0x199/0x2f0[ 1010.716016] ? asm_exc_general_protection+0x1e/0x30[ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp][ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp][ 1010.716042] __rtnl_newlink+0x1063/0x1700[ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0[ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0[ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0[ 1010.716076] ? __kernel_text_address+0x56/0xa0[ 1010.716084] ? unwind_get_return_address+0x5a/0xa0[ 1010.716091] ? create_prof_cpu_mask+0x30/0x30[ 1010.716098] ? arch_stack_walk+0x9e/0xf0[ 1010.716106] ? stack_trace_save+0x91/0xd0[ 1010.716113] ? stack_trace_consume_entry+0x170/0x170[ 1010.716121] ? __lock_acquire+0x15c5/0x5380[ 1010.716139] ? mark_held_locks+0x9e/0xe0[ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0[ 1010.716155] ? __rtnl_newlink+0x1700/0x1700[ 1010.716160] rtnl_newlink+0x69/0xa0[ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50[ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0[ 1010.716179] ? lock_acquire+0x1fe/0x560[ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50[ 1010.716196] netlink_rcv_skb+0x14d/0x440[ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0[ 1010.716208] ? netlink_ack+0xab0/0xab0[ 1010.716213] ? netlink_deliver_tap+0x202/0xd50[ 1010.716220] ? netlink_deliver_tap+0x218/0xd50[ 1010.716226] ? __virt_addr_valid+0x30b/0x590[ 1010.716233] netlink_unicast+0x54b/0x800[ 1010.716240] ? netlink_attachskb+0x870/0x870[ 1010.716248] ? __check_object_size+0x2de/0x3b0[ 1010.716254] netlink_sendmsg+0x938/0xe40[ 1010.716261] ? netlink_unicast+0x800/0x800[ 1010.716269] ? __import_iovec+0x292/0x510[ 1010.716276] ? netlink_unicast+0x800/0x800[ 1010.716284] __sock_sendmsg+0x159/0x190[ 1010.716290] ____sys_sendmsg+0x712/0x880[ 1010.716297] ? sock_write_iter+0x3d0/0x3d0[ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270[ 1010.716309] ? lock_acquire+0x1fe/0x560[ 1010.716315] ? drain_array_locked+0x90/0x90[ 1010.716324] ___sys_sendmsg+0xf8/0x170[ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170[ 1010.716337] ? lockdep_init_map---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26798 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: always restore the old font data in fbcon_do_set_font()Commit a5a923038d70 (fbdev: fbcon: Properly revert changes whenvc_resize() failed) started restoring old font data upon failure (ofvc_resize()). But it performs so only for user fonts. It means that the"system"/internal fonts are not restored at all. So in result, the veryfirst call to fbcon_do_set_font() performs no restore at all uponfailing vc_resize().This can be reproduced by Syzkaller to crash the system on the nextinvocation of font_get(). It's rather hard to hit the allocation failurein vc_resize() on the first font_set(), but not impossible. Esp. iffault injection is used to aid the execution/failure. It wasdemonstrated by Sirius: BUG: unable to handle page fault for address: fffffffffffffff8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Call Trace: con_font_get drivers/tty/vt/vt.c:4558 [inline] con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673 vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline] vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803 vfs_ioctl fs/ioctl.c:51 [inline] ...So restore the font data in any case, not only for user fonts. Note thelater 'if' is now protected by 'old_userfont' and not 'old_data' as thelatter is always set now. (And it is supposed to be non-NULL. Otherwisewe would see the bug above again.)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26801 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Avoid potential use-after-free in hci_error_resetWhile handling the HCI_EV_HARDWARE_ERROR event, if the underlyingBT controller is not responding, the GPIO reset mechanism wouldfree the hci_dev and lead to a use-after-free in hci_error_reset.Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth ] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth ] hci_error_reset+0x4f/0xa4 [bluetooth ] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30This patch holds the reference count on the hci_dev while processinga HCI_EV_HARDWARE_ERROR event to avoid potential crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26802 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:stmmac: Clear variable when destroying workqueueCurrently when suspending driver and stopping workqueue it is checked whetherworkqueue is not NULL and if so, it is destroyed.Function destroy_workqueue() does drain queue and does clear variable, butit does not set workqueue variable to NULL. This can cause kernel/modulepanic if code attempts to clear workqueue that was not initialized.This scenario is possible when resuming suspended driver in stmmac_resume(),because there is no handling for failed stmmac_hw_setup(),which can fail and return if DMA engine has failed to initialize,and workqueue is initialized after DMA engine.Should DMA engine fail to initialize, resume will proceed normally,but interface won't work and TX queue will eventually timeout,causing 'Reset adapter' error.This then does destroy workqueue during reset process.And since workqueue is initialized after DMA engine and can be skipped,it will cause kernel/module panic.To secure against this possible crash, set workqueue variable to NULL whendestroying workqueue.Log/backtrace from crash goes as follows:[88.031977]------------[ cut here ]------------[88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out[88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398 [88.032251]---[ end trace e70de432e4d5c2c0 ]---[88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter.[88.036359]------------[ cut here ]------------[88.036519]Call trace:[88.036523] flush_workqueue+0x3e4/0x430[88.036528] drain_workqueue+0xc4/0x160[88.036533] destroy_workqueue+0x40/0x270[88.036537] stmmac_fpe_stop_wq+0x4c/0x70[88.036541] stmmac_release+0x278/0x280[88.036546] __dev_close_many+0xcc/0x158[88.036551] dev_close_many+0xbc/0x190[88.036555] dev_close.part.0+0x70/0xc0[88.036560] dev_close+0x24/0x30[88.036564] stmmac_service_task+0x110/0x140[88.036569] process_one_work+0x1d8/0x4a0[88.036573] worker_thread+0x54/0x408[88.036578] kthread+0x164/0x170[88.036583] ret_from_fork+0x10/0x20[88.036588]---[ end trace e70de432e4d5c2c1 ]---[88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26804 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ip_tunnel: prevent perpetual headroom growthsyzkaller triggered following kasan splat:BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191[..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ...The splat occurs because skb->data points past skb->head allocated area.This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb));... but skb_network_offset() returns a negative offset and __skb_pull()arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.The negative value is returned because skb->head and skb->data distance ismore than 64k and skb->network_header (u16) has wrapped around.The bug is in the ip_tunnel infrastructure, which can causedev->needed_headroom to increment ad infinitum.The syzkaller reproducer consists of packets getting routed via a gretunnel, and route of gre encapsulated packets pointing at another (ipip)tunnel. The ipip encapsulation finds gre0 as next output device.This results in the following pattern:1). First packet is to be sent out via gre0.Route lookup found an output device, ipip0.2).ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the futureoutput device, rt.dev->needed_headroom (ipip0).3).ip output / start_xmit moves skb on to ipip0. which runs the samecode path again (xmit recursion).4).Routing step for the post-gre0-encap packet finds gre0 as output deviceto use for ipip0 encapsulated packet.tunl0->needed_headroom is then incremented based on the (already bumped)gre0 device headroom.This repeats for every future packet:gre0->needed_headroom gets inflated because previous packets' ipip0 stepincremented rt->dev (gre0) headroom, and ipip0 incremented because gre0needed_headroom was increased.For each subsequent packet, gre/ipip0->needed_headroom grows untilpost-expand-head reallocations result in a skb->head/data distance ofmore than 64k.Once that happens, skb->network_header (u16) wraps around whenpskb_expand_head tries to make sure that skb_network_offset() is unchangedafter the headroom expansion/reallocation.After this skb_network_offset(skb) returns a different (and negative)result post headroom expansion.The next trip to neigh layer (or anything else that would __skb_pull thenetwork header) makes skb->data point to a memory location outsideskb->head area.v2: Cap the needed_headroom update to an arbitarily chosen upperlimit toprevent perpetual increase instead of dropping the headroom incrementcompletely.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26805 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: Fix kernel-infoleak-after-free in __skb_datagram_itersyzbot reported the following uninit-value access issue [1]:netlink_to_full_skb() creates a new `skb` and puts the `skb->data`passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The datasize is specified as `len` and passed to skb_put_data(). This `len`is based on `skb->end` that is not data offset but buffer offset. The`skb->end` contains data and tailroom. Since the tailroom is notinitialized when the new `skb` created, KMSAN detects uninitializedmemory area when copying the data.This patch resolved this issue by correct the len from `skb->end` to`skb->len`, which is the actual data offset.BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26807 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Both cadence-quadspi ->runtime_suspend() and ->runtime_resume()implementations start with: struct cqspi_st *cqspi = dev_get_drvdata(dev); struct spi_controller *host = dev_get_drvdata(dev);This obviously cannot be correct, unless "struct cqspi_st" is thefirst member of " struct spi_controller", or the other way around, butit is not the case. "struct spi_controller" is allocated bydevm_spi_alloc_host(), which allocates an extra amount of memory forprivate data, used to store "struct cqspi_st".The ->probe() function of the cadence-quadspi driver then sets thedevice drvdata to store the address of the "struct cqspi_st"structure. Therefore: struct cqspi_st *cqspi = dev_get_drvdata(dev);is correct, but: struct spi_controller *host = dev_get_drvdata(dev);is not, as it makes "host" point not to a "struct spi_controller" butto the same "struct cqspi_st" structure as above.This obviously leads to bad things (memory corruption, kernel crashes)directly during ->probe(), as ->probe() enables the device using PMruntime, leading the ->runtime_resume() hook being called, which inturns calls spi_controller_resume() with the wrong pointer.This has at least been reported [0] to cause a kernel crash, but theexact behavior will depend on the memory contents.[0] https://lore.kernel.org/all/20240226121803.5a7r5wkpbbowcxgx@dhruva/This issue potentially affects all platforms that are currently usingthe cadence-quadspi driver.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26822 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: set correct id, uid and cruid for multiuser automountsWhen uid, gid and cruid are not specified, we need to dynamicallyset them into the filesystem context used for automounting otherwisethey'll end up reusing the values from the parent mount.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26825 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: free rx_data_reassembly skb on NCI device cleanuprx_data_reassembly skb is stored during NCI data exchange for processingfragmented packets. It is dropped only when the last fragment is processedor when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.However, the NCI device may be deallocated before that which leads to skbleak.As by design the rx_data_reassembly skb is bound to the NCI device andnothing prevents the device to be freed before the skb is processed insome way and cleaned, free it on the NCI device cleanup.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26829 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: ir_toy: fix a memleak in irtoy_txWhen irtoy_command fails, buf should be freed since it is allocated byirtoy_tx, or there is a memleak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26830 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Do not allow untrusted VF to remove administratively set MACCurrently when PF administratively sets VF's MAC address and the VFis put down (VF tries to delete all MACs) then the MAC is removedfrom MAC filters and primary VF MAC is zeroed.Do not allow untrusted VF to remove primary MAC when it was setadministratively by PF.Reproducer:1) Create VF2) Set VF interface up3) Administratively set the VF's MAC4) Put VF interface down[root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs[root@host ~]# ip link set enp2s0f0v0 up[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d[root@host ~]# ip link show enp2s0f023: enp2s0f0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off[root@host ~]# ip link set enp2s0f0v0 down[root@host ~]# ip link show enp2s0f023: enp2s0f0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26833 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix memory leak in dm_sw_fini()After destroying dmub_srv, the memory associated with it isnot freed, causing a memory leak:unreferenced object 0xffff896302b45800 (size 1024): comm "(udev-worker)", pid 222, jiffies 4294894636 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 00 00 00 00 00 00 00 ................ backtrace (crc 6265fd77): [] kmalloc_trace+0x29d/0x340 [] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [] dm_sw_init+0x15/0x2b0 [amdgpu] [] amdgpu_device_init+0x1417/0x24e0 [amdgpu] [] amdgpu_driver_load_kms+0x15/0x190 [amdgpu] [] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [] local_pci_probe+0x3e/0x90 [] pci_device_probe+0xc3/0x230 [] really_probe+0xe2/0x480 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x112/0x210 [] driver_register+0x55/0x100 [] do_one_initcall+0x41/0x300Fix this by freeing dmub_srv after destroying it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26838 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Fix KASAN issue with taskletKASAN testing revealed the following issue assocated with freeing an IRQ.[50006.466686] Call Trace:[50006.466691] [50006.489538] dump_stack+0x5c/0x80[50006.493475] print_address_description.constprop.6+0x1a/0x150[50006.499872] ? irdma_sc_process_ceq+0x483/0x790 [irdma][50006.505742] ? irdma_sc_process_ceq+0x483/0x790 [irdma][50006.511644] kasan_report.cold.11+0x7f/0x118[50006.516572] ? irdma_sc_process_ceq+0x483/0x790 [irdma][50006.522473] irdma_sc_process_ceq+0x483/0x790 [irdma][50006.528232] irdma_process_ceq+0xb2/0x400 [irdma][50006.533601] ? irdma_hw_flush_wqes_callback+0x370/0x370 [irdma][50006.540298] irdma_ceq_dpc+0x44/0x100 [irdma][50006.545306] tasklet_action_common.isra.14+0x148/0x2c0[50006.551096] __do_softirq+0x1d0/0xaf8[50006.555396] irq_exit_rcu+0x219/0x260[50006.559670] irq_exit+0xa/0x20[50006.563320] smp_apic_timer_interrupt+0x1bf/0x690[50006.568645] apic_timer_interrupt+0xf/0x20[50006.573341] The issue is that a tasklet could be pending on another core racingthe delete of the irq.Fix by insuring any scheduled tasklet is killed after deleting theirq.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26843 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:efi: runtime: Fix potential overflow of soft-reserved region sizemd_size will have been narrowed if we have >= 4GB worth of pages in asoft-reserved region.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26851 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_h323: Add protection for bmp length out of rangeUBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shiftsthat are out of bounds for their data type.vmlinux get_bitmap(b=75) + 712vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216vmlinux DecodeRasMessage() + 304vmlinux ras_help() + 684vmlinux nf_confirm() + 188Due to abnormal data in skb->data, the extension bitmap lengthexceeds 32 when decoding ras message then uses the length to makea shift operation. It will change into negative after several loop.UBSAN load could detect a negative shift as an undefined behaviourand reports exception.So we add the protection to avoid the length exceeding 32. Or elseit will return out of range error and stop decoding.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:igc: avoid returning frame twice in XDP_REDIRECTWhen a frame can not be transmitted in XDP_REDIRECT(e.g. due to a full queue), it is necessary to freeit by calling xdp_return_frame_rx_napi.However, this is the responsibility of the caller ofthe ndo_xdp_xmit (see for example bq_xmit_all inkernel/bpf/devmap.c) and thus calling it insideigc_xdp_xmit (which is the ndo_xdp_xmit of the igcdriver) as well will lead to memory corruption.In fact, bq_xmit_all expects that it can return allframes after the last successfully transmitted one.Therefore, break for the first not transmitted frame,but do not call xdp_return_frame_rx_napi in igc_xdp_xmit.This is equally implemented in other Intel driverssuch as the igb.There are two alternatives to this that were rejected:1. Return num_frames as all the frames would have been transmitted and release them inside igc_xdp_xmit. While it might work technically, it is not what the return value is meant to represent (i.e. the number of SUCCESSFULLY transmitted packets).2. Rework kernel/bpf/devmap.c and all drivers to support non-consecutively dropped packets. Besides being complex, it likely has a negative performance impact without a significant gain since it is anyway unlikely that the next frame can be transmitted if the previous one was dropped.The memory corruption can be reproduced withthe following script which leads to a kernel panicafter a few seconds. It basically generates moretraffic than a i225 NIC can transmit and pushes itvia XDP_REDIRECT from a virtual interface to thephysical interface where frames get dropped. #!/bin/bash INTERFACE=enp4s0 INTERFACE_IDX=`cat /sys/class/net/$INTERFACE/ifindex` sudo ip link add dev veth1 type veth peer name veth2 sudo ip link set up $INTERFACE sudo ip link set up veth1 sudo ip link set up veth2 cat << EOF > redirect.bpf.c SEC("prog") int redirect(struct xdp_md *ctx) { return bpf_redirect($INTERFACE_IDX, 0); } char _license[] SEC("license") = "GPL"; EOF clang -O2 -g -Wall -target bpf -c redirect.bpf.c -o redirect.bpf.o sudo ip link set veth2 xdp obj redirect.bpf.o cat << EOF > pass.bpf.c SEC("prog") int pass(struct xdp_md *ctx) { return XDP_PASS; } char _license[] SEC("license") = "GPL"; EOF clang -O2 -g -Wall -target bpf -c pass.bpf.c -o pass.bpf.o sudo ip link set $INTERFACE xdp obj pass.bpf.o cat << EOF > trafgen.cfg { /* Ethernet Header */ 0xe8, 0x6a, 0x64, 0x41, 0xbf, 0x46, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, const16(ETH_P_IP), /* IPv4 Header */ 0b01000101, 0, # IPv4 version, IHL, TOS const16(1028), # IPv4 total length (UDP length + 20 bytes (IP header)) const16(2), # IPv4 ident 0b01000000, 0, # IPv4 flags, fragmentation off 64, # IPv4 TTL 17, # Protocol UDP csumip(14, 33), # IPv4 checksum /* UDP Header */ 10, 0, 1, 1, # IP Src - adapt as needed 10, 0, 1, 2, # IP Dest - adapt as needed const16(6666), # UDP Src Port const16(6666), # UDP Dest Port const16(1008), # UDP length (UDP header 8 bytes + payload length) csumudp(14, 34), # UDP checksum /* Payload */ fill('W', 1000), } EOF sudo trafgen -i trafgen.cfg -b3000MB -o veth1 --cpp

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()The function ice_bridge_setlink() may encounter a NULL pointer dereferenceif nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequentlyin nla_for_each_nested(). To address this issue, add a check to ensure thatbr_spec is not NULL before proceeding with the nested attribute iteration.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26856 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sparx5: Fix use after free inside sparx5_del_mact_entryBased on the static analyzis of the code it looks like when an entryfrom the MAC table was removed, the entry was still used after beingfreed. More precise the vid of the mac_entry was used after callingdevm_kfree on the mac_entry.The fix consists in first using the vid of the mac_entry to delete theentry from the HW and after that to free it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:geneve: make sure to pull inner header in geneve_rx()syzbot triggered a bug in geneve_rx() [1]Issue is similar to the one I fixed in commit 8d975c15c0cd("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")We have to save skb->network_header in a temporary variablein order to be able to recompute the network_header pointerafter a pskb_inet_may_pull() call.pskb_inet_may_pull() makes sure the needed headers are in skb->head.[1]BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346 __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778 __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454 __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26859 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/bnx2x: Prevent access to a freed page in page_poolFix race condition leading to system crash during EEH error handlingDuring EEH error recovery, the bnx2x driver's transmit timeout logiccould cause a race condition when handling reset tasks. Thebnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()SGEs are freed using bnx2x_free_rx_sge_range(). However, this couldoverlap with the EEH driver's attempt to reset the device usingbnx2x_io_slot_reset(), which also tries to free SGEs. This racecondition can result in system crashes due to accessing freed memorylocations in bnx2x_free_rx_sge()799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp,800 struct bnx2x_fastpath *fp, u16 index)801 {802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index];803 struct page *page = sw_buf->page;....where sw_buf was set to NULL after the call to dma_unmap_page()by the preceding thread. EEH: Beginning: 'slot_reset' PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset() bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing... bnx2x 0011:01:00.0: enabling device (0140 -> 0142) bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000025065fc Oops: Kernel access of bad area, sig: 11 [#1] ..... Call Trace: [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable) [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0 [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550 [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60 [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170 [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0 [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64To solve this issue, we need to verify page pool allocations beforefreeing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26861 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wireguard: receive: annotate data-race around receiving_counter.counterSyzkaller with KCSAN identified a data-race issue when accessingkeypair->receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE()annotations to mark the data race as intentional. BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0: counter_validate drivers/net/wireguard/receive.c:321 [inline] wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461 __napi_poll+0x60/0x3b0 net/core/dev.c:6536 napi_poll net/core/dev.c:6605 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6738 __do_softirq+0xc4/0x279 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline] wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499 process_one_work kernel/workqueue.c:2633 [inline] ... read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1: decrypt_packet drivers/net/wireguard/receive.c:252 [inline] wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706 worker_thread+0x525/0x730 kernel/workqueue.c:2787 ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hsr: Fix uninit-value access in hsr_get_node()KMSAN reported the following uninit-value access issue [1]:=====================================================BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [inline] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bCPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023=====================================================If the packet type ID field in the Ethernet header is either ETH_P_PRP orETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()reads an invalid value as a sequence number. This causes the above issue.This patch fixes the issue by returning NULL if the Ethernet header is notfollowed by an HSR tag.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26866 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: lpspi: Avoid potential use-after-free in probe()fsl_lpspi_probe() is allocating/disposing memory manually withspi_alloc_host()/spi_alloc_target(), but usesdevm_spi_register_controller(). In case of error after the latter call thememory will be explicitly freed in the probe function byspi_controller_put() call, but used afterwards by "devm" management outsideprobe() (spi_unregister_controller() <- devm_spi_unregister() below).Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070...Call trace: kernfs_find_ns kernfs_find_and_get_ns sysfs_remove_group sysfs_remove_groups device_remove_attrs device_del spi_unregister_controller devm_spi_unregister release_nodes devres_release_all really_probe driver_probe_device __device_attach_driver bus_for_each_drv __device_attach device_initial_probe bus_probe_device deferred_probe_work_func process_one_work worker_thread kthread ret_from_fork

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26870 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102A call to listxattr() with a buffer size = 0 returns the actualsize of the buffer needed for a subsequent call. When size > 0,nfs4_listxattr() does not return an error because eithergeneric_listxattr() or nfs4_listxattr_nfs4_label() consumesexactly all the bytes then size is 0 when callingnfs4_listxattr_nfs4_user() which then triggers the followingkernel BUG: [ 99.403778] kernel BUG at mm/usercopy.c:102! [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Call trace: [ 99.415985] usercopy_abort+0x70/0xa0 [ 99.416227] __check_heap_object+0x134/0x158 [ 99.416505] check_heap_object+0x150/0x188 [ 99.416696] __check_object_size.part.0+0x78/0x168 [ 99.416886] __check_object_size+0x28/0x40 [ 99.417078] listxattr+0x8c/0x120 [ 99.417252] path_listxattr+0x78/0xe0 [ 99.417476] __arm64_sys_listxattr+0x28/0x40 [ 99.417723] invoke_syscall+0x78/0x100 [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0 [ 99.418186] do_el0_svc+0x24/0x38 [ 99.418376] el0_svc+0x3c/0x110 [ 99.418554] el0t_64_sync_handler+0x120/0x130 [ 99.418788] el0t_64_sync+0x194/0x198 [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl',thus calling lisxattr() with size = 16 will trigger the bug.Add check on nfs4_listxattr() to return ERANGE error when it iscalled with size > 0 and the return value is greater than size.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26872 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/srpt: Do not register event handler until srpt device is fully setupUpon rare occasions, KASAN reports a use-after-free Writein srpt_refresh_port().This seems to be because an event handler is registered before thesrpt device is fully setup and a race condition upon error may leave apartially setup event handler in place.Instead, only register the event handler after srpt device initializationis complete.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26874 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flipIt's possible that mtk_crtc->event is NULL inmtk_drm_crtc_finish_page_flip().pending_needs_vblank value is set by mtk_crtc->event, but inmtk_drm_crtc_atomic_flush(), it's is not guarded by the samelock in mtk_drm_finish_page_flip(), thus a race condition happens.Consider the following case:CPU1 CPU2step 1:mtk_drm_crtc_atomic_begin()mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event)step 2:mtk_crtc_ddp_irq ->mtk_drm_finish_page_flip:lockmtk_crtc->event set to null,pending_needs_vblank set to falseunlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointerInstead of guarding the entire mtk_drm_crtc_atomic_flush(), it's moreefficient to just check if mtk_crtc->event is null before use.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26876 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/bridge: adv7511: fix crash on irq during probeMoved IRQ registration down to end of adv7511_probe().If an IRQ already is pending during adv7511_probe(before adv7511_cec_init) then cec_received_msg_tscould crash using uninitialized data: Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5 Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP Call trace: cec_received_msg_ts+0x48/0x990 [cec] adv7511_cec_irq_process+0x1cc/0x308 [adv7511] adv7511_irq_process+0xd8/0x120 [adv7511] adv7511_irq_handler+0x1c/0x30 [adv7511] irq_thread_fn+0x30/0xa0 irq_thread+0x14c/0x238 kthread+0x190/0x1a8

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26879 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: meson: Add missing clocks to axg_clk_regmapsSome clocks were missing from axg_clk_regmaps, which caused kernel panicduring cat /sys/kernel/debug/clk/clk_summary[ 57.349402] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc...[ 57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 57.436900] pc : regmap_read+0x1c/0x88[ 57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0[ 57.445611] sp : ffff800082f1b690[ 57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080eb9a70[ 57.455961] x26: 0000000000000007 x25: 0000000000000016 x24: 0000000000000000[ 57.463033] x23: ffff800080e8b488 x22: 0000000000000015 x21: ffff00000e7e7000[ 57.470106] x20: ffff00000400ec00 x19: 0000000000000000 x18: ffffffffffffffff[ 57.477178] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000042a3000[ 57.484251] x14: 0000000000000000 x13: ffff0000042a2fec x12: 0000000005f5e100[ 57.491323] x11: abcc77118461cefd x10: 0000000000000020 x9 : ffff8000805e4b24[ 57.498396] x8 : ffff0000028063c0 x7 : ffff800082f1b710 x6 : ffff800082f1b710[ 57.505468] x5 : 00000000ffffffd0 x4 : ffff800082f1b6e0 x3 : 0000000000001000[ 57.512541] x2 : ffff800082f1b6e4 x1 : 000000000000012c x0 : 0000000000000000[ 57.519615] Call trace:[ 57.522030] regmap_read+0x1c/0x88[ 57.525393] clk_regmap_gate_is_enabled+0x3c/0xb0[ 57.530050] clk_core_is_enabled+0x44/0x120[ 57.534190] clk_summary_show_subtree+0x154/0x2f0[ 57.538847] clk_summary_show_subtree+0x220/0x2f0[ 57.543505] clk_summary_show_subtree+0x220/0x2f0[ 57.548162] clk_summary_show_subtree+0x220/0x2f0[ 57.552820] clk_summary_show_subtree+0x220/0x2f0[ 57.557477] clk_summary_show_subtree+0x220/0x2f0[ 57.562135] clk_summary_show_subtree+0x220/0x2f0[ 57.566792] clk_summary_show_subtree+0x220/0x2f0[ 57.571450] clk_summary_show+0x84/0xb8[ 57.575245] seq_read_iter+0x1bc/0x4b8[ 57.578954] seq_read+0x8c/0xd0[ 57.582059] full_proxy_read+0x68/0xc8[ 57.585767] vfs_read+0xb0/0x268[ 57.588959] ksys_read+0x70/0x108[ 57.592236] __arm64_sys_read+0x24/0x38[ 57.596031] invoke_syscall+0x50/0x128[ 57.599740] el0_svc_common.constprop.0+0x48/0xf8[ 57.604397] do_el0_svc+0x28/0x40[ 57.607675] el0_svc+0x34/0xb8[ 57.610694] el0t_64_sync_handler+0x13c/0x158[ 57.615006] el0t_64_sync+0x190/0x198[ 57.618635] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00)[ 57.624668] ---[ end trace 0000000000000000 ]---[jbrunet: add missing Fixes tag]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when 1588 is received on HIP08 devicesThe HIP08 devices does not register the ptp devices, so thehdev->ptp is NULL, but the hardware can receive 1588 messages,and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, theaccess of hdev->ptp->flags will cause a kernel crash:[ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018[ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018...[ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge][ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge][ 5889.279101] sp : ffff800012c3bc50[ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040[ 5889.289927] x27: ffff800009116484 x26: 0000000080007500[ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000[ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000[ 5889.309134] x21: 0000000000000000 x20: ffff204004220080[ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000[ 5889.321897] x17: 0000000000000000 x16: 0000000000000000[ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000[ 5889.334617] x13: 0000000000000000 x12: 00000000010011df[ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000[ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d[ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480[ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000[ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000[ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080[ 5889.378857] Call trace:[ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge][ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3][ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3][ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3][ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3][ 5889.411084] napi_poll+0xcc/0x264[ 5889.415329] net_rx_action+0xd4/0x21c[ 5889.419911] __do_softirq+0x130/0x358[ 5889.424484] irq_exit+0x134/0x154[ 5889.428700] __handle_domain_irq+0x88/0xf0[ 5889.433684] gic_handle_irq+0x78/0x2c0[ 5889.438319] el1_irq+0xb8/0x140[ 5889.442354] arch_cpu_idle+0x18/0x40[ 5889.446816] default_idle_call+0x5c/0x1c0[ 5889.451714] cpuidle_idle_call+0x174/0x1b0[ 5889.456692] do_idle+0xc8/0x160[ 5889.460717] cpu_startup_entry+0x30/0xfc[ 5889.465523] secondary_start_kernel+0x158/0x1ec[ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)[ 5889.477950] SMP: stopping secondary CPUs[ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95[ 5890.522951] Starting crashdump kernel...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26882 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()Apply the same fix than ones found in :8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()")We have to save skb->network_header in a temporary variablein order to be able to recompute the network_header pointerafter a pskb_inet_may_pull() call.pskb_inet_may_pull() makes sure the needed headers are in skb->head.syzbot reported: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 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389 ipgre_rcv net/ipv4/ip_gre.c:411 [inline] gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447 gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 netif_receive_skb_internal net/core/dev.c:5734 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5793 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556 tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133 alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204 skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909 tun_build_skb drivers/net/tun.c:1686 [inline] tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26883 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stackmap overflow check on 32-bit archesThe stackmap code relies on roundup_pow_of_two() to compute the numberof hash buckets, and contains an overflow check by checking if theresulting value is 0. However, on 32-bit arches, the roundup code itselfcan overflow by doing a 32-bit left-shift of an unsigned long value,which is undefined behaviour, so it is not guaranteed to truncateneatly. This was triggered by syzbot on the DEVMAP_HASH type, whichcontains the same check, copied from the hashtab code.The commit in the fixes tag actually attempted to fix this, but the fixdid not account for the UB, so the fix only works on CPUs where anoverflow does result in a neat truncation to zero, which is notguaranteed. Checking the value before rounding does not have thisproblem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26884 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix hashtab overflow check on 32-bit archesThe hashtab code relies on roundup_pow_of_two() to compute the number ofhash buckets, and contains an overflow check by checking if theresulting value is 0. However, on 32-bit arches, the roundup code itselfcan overflow by doing a 32-bit left-shift of an unsigned long value,which is undefined behaviour, so it is not guaranteed to truncateneatly. This was triggered by syzbot on the DEVMAP_HASH type, whichcontains the same check, copied from the hashtab code. So apply the samefix to hashtab, by moving the overflow check to before the roundup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26885 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix DEVMAP_HASH overflow check on 32-bit archesThe devmap code allocates a number hash buckets equal to the next powerof two of the max_entries value provided when creating the map. Whenrounding up to the next power of two, the 32-bit variable storing thenumber of buckets can overflow, and the code checks for overflow bychecking if the truncated 32-bit value is equal to 0. However, on 32-bitarches the rounding up itself can overflow mid-way through, because itends up doing a left-shift of 32 bits on an unsigned long value. If thesize of an unsigned long is four bytes, this is undefined behaviour, sothere is no guarantee that we'll end up with a nice and tidy 0-value atthe end.Syzbot managed to turn this into a crash on arm32 by creating aDEVMAP_HASH with max_entries > 0x80000000 and then trying to update it.Fix this by moving the overflow check to before the rounding upoperation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26886 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: af_bluetooth: Fix deadlockAttemting to do sock_lock on .recvmsg may cause a deadlock as shownbellow, so instead of using sock_sock this uses sk_receive_queue.lockon bt_sock_ioctl to avoid the UAF:INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183Workqueue: hci0 hci_rx_workCall Trace: __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26894 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()After unregistering the CPU idle device, the memory associated withit is not freed, leading to a memory leak:unreferenced object 0xffff896282f6c000 (size 1024): comm "swapper/0", pid 1, jiffies 4294893170 hex dump (first 32 bytes): 00 00 00 00 0b 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 8836a742): [] kmalloc_trace+0x29d/0x340 [] acpi_processor_power_init+0xf3/0x1c0 [] __acpi_processor_start+0xd3/0xf0 [] acpi_processor_start+0x2c/0x50 [] really_probe+0xe2/0x480 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x112/0x210 [] driver_register+0x55/0x100 [] acpi_processor_driver_init+0x3b/0xc0 [] do_one_initcall+0x41/0x300 [] kernel_init_freeable+0x320/0x470 [] kernel_init+0x16/0x1b0 [] ret_from_fork+0x2d/0x50Fix this by freeing the CPU idle device after unregistering it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26896 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wfx: fix memory leak when starting APKmemleak reported this error: unreferenced object 0xd73d1180 (size 184): comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s) 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 1e 00 01 00 00 00 00 00 ................ backtrace: [<5ca11420>] kmem_cache_alloc+0x20c/0x5ac [<127bdd74>] __alloc_skb+0x144/0x170 [] __netdev_alloc_skb+0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211] [] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] netlink_unicast+0x1b4/0x258 [] netlink_sendmsg+0x1e8/0x428 [] ____sys_sendmsg+0x1e0/0x274 [] ___sys_sendmsg+0x80/0xb4 [<69954f45>] __sys_sendmsg+0x64/0xa8 unreferenced object 0xce087000 (size 1024): comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<9a993714>] __kmalloc_track_caller+0x230/0x600 [] kmalloc_reserve.constprop.0+0x30/0x74 [] __alloc_skb+0xa0/0x170 [] __netdev_alloc_skb+0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211] [] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] netlink_unicast+0x1b4/0x258 [] netlink_sendmsg+0x1e8/0x428 [] ____sys_sendmsg+0x1e0/0x274 [] ___sys_sendmsg+0x80/0xb4However, since the kernel is build optimized, it seems the stack is notaccurate. It appears the issue is related to wfx_set_mfp_ap(). The issueis obvious in this function: memory allocated by ieee80211_beacon_get()is never released. Fixing this leak makes kmemleak happy.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26900 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md: fix kmemleak of rdev->serialIf kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will bealloc not be freed, and kmemleak occurs.unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 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 00 00 00 00 00 00 00 ................ backtrace (crc f773277a): [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] kvmalloc_node+0x74/0x150 [<0000000034bf3363>] rdev_init_serial+0x67/0x170 [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [<0000000085086a11>] vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>] do_syscall_64+0x71/0x150 [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26915 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Reset IH OVERFLOW_CLEAR bitAllows us to detect subsequent IH ring buffer overflows as well.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: validate the parameters of bo mapping operations more clearlyVerify the parameters ofamdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26934 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix deadlock in usb_deauthorize_interface()Among the attribute file callback routines indrivers/usb/core/sysfs.c, the interface_authorized_store() function isthe only one which acquires a device lock on an ancestor device: Itcalls usb_deauthorize_interface(), which locks the interface's parentUSB device.The will lead to deadlock if another process already owns that lockand tries to remove the interface, whether through a configurationchange or because the device has been disconnected. As part of theremoval procedure, device_del() waits for all ongoing sysfs attributecallbacks to complete. But usb_deauthorize_interface() can't completeuntil the device lock has been released, and the lock won't bereleased until the removal has finished.The mechanism provided by sysfs to prevent this kind of deadlock isto use the sysfs_break_active_protection() function, which tells sysfsnot to wait for the attribute callback.Reported-and-tested by: Yue Sun Reported by: xingwei lee

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26950 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wireguard: netlink: access device through ctx instead of peerThe previous commit fixed a bug that led to a NULL peer->device beingdereferenced. It's actually easier and faster performance-wise toinstead get the device from ctx->wg. This semantically makes more sensetoo, since ctx->wg->peer_allowedips.seq is compared withctx->allowedips_seq, basing them both in ctx. This also acts as adefence in depth provision against freed peers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26953 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: esp: fix bad handling of pages from page_poolWhen the skb is reorganized during esp_output (!esp->inline), the pagescoming from the original skb fragments are supposed to be released backto the system through put_page. But if the skb fragment pages areoriginating from a page_pool, calling put_page on them will trigger apage_pool leak which will eventually result in a crash.This leak can be easily observed when using CONFIG_DEBUG_VM and doingipsec + gre (non offloaded) forwarding: BUG: Bad page state in process ksoftirqd/16 pfn:1451b6 page:00000000de2b8d32 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1451b6000 pfn:0x1451b6 flags: 0x200000000000000(node=0|zone=2) page_type: 0xffffffff() raw: 0200000000000000 dead000000000040 ffff88810d23c000 0000000000000000 raw: 00000001451b6000 0000000000000001 00000000ffffffff 0000000000000000 page dumped because: page_pool leak Modules linked in: ip_gre gre mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay zram zsmalloc fuse [last unloaded: mlx5_core] CPU: 16 PID: 96 Comm: ksoftirqd/16 Not tainted 6.8.0-rc4+ #22 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x36/0x50 bad_page+0x70/0xf0 free_unref_page_prepare+0x27a/0x460 free_unref_page+0x38/0x120 esp_ssg_unref.isra.0+0x15f/0x200 esp_output_tail+0x66d/0x780 esp_xmit+0x2c5/0x360 validate_xmit_xfrm+0x313/0x370 ? validate_xmit_skb+0x1d/0x330 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x23e/0x350 __dev_queue_xmit+0x337/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x25e/0x580 iptunnel_xmit+0x19b/0x240 ip_tunnel_xmit+0x5fb/0xb60 ipgre_xmit+0x14d/0x280 [ip_gre] dev_hard_start_xmit+0xc3/0x1c0 __dev_queue_xmit+0x208/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x1ca/0x580 ip_sublist_rcv_finish+0x32/0x40 ip_sublist_rcv+0x1b2/0x1f0 ? ip_rcv_finish_core.constprop.0+0x460/0x460 ip_list_rcv+0x103/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x1b3/0x2c0 napi_gro_receive+0xc8/0x200 gro_cell_poll+0x52/0x90 __napi_poll+0x25/0x1a0 net_rx_action+0x28e/0x300 __do_softirq+0xc3/0x276 ? sort_range+0x20/0x20 run_ksoftirqd+0x1e/0x30 smpboot_thread_fn+0xa6/0x130 kthread+0xcd/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x31/0x50 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20 The suggested fix is to introduce a new wrapper (skb_page_unref) thatcovers page refcounting for page_pool pages as well.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26957 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/zcrypt: fix reference counting on zcrypt card objectsTests with hot-plugging crytpo cards on KVM guests with debugkernel build revealed an use after free for the load field ofthe struct zcrypt_card. The reason was an incorrect referencehandling of the zcrypt card object which could lead to a freeof the zcrypt card object while it was still in use.This is an example of the slab message: kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43 kernel: kmalloc_trace+0x3f2/0x470 kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt] kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4] kernel: ap_device_probe+0x15c/0x290 kernel: really_probe+0xd2/0x468 kernel: driver_probe_device+0x40/0xf0 kernel: __device_attach_driver+0xc0/0x140 kernel: bus_for_each_drv+0x8c/0xd0 kernel: __device_attach+0x114/0x198 kernel: bus_probe_device+0xb4/0xc8 kernel: device_add+0x4d2/0x6e0 kernel: ap_scan_adapter+0x3d0/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43 kernel: kfree+0x37e/0x418 kernel: zcrypt_card_put+0x54/0x80 [zcrypt] kernel: ap_device_remove+0x4c/0xe0 kernel: device_release_driver_internal+0x1c4/0x270 kernel: bus_remove_device+0x100/0x188 kernel: device_del+0x164/0x3c0 kernel: device_unregister+0x30/0x90 kernel: ap_scan_adapter+0xc8/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: kthread+0x150/0x168 kernel: __ret_from_fork+0x3c/0x58 kernel: ret_from_fork+0xa/0x30 kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff) kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88 kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........ kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk. kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........ kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2 kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux) kernel: Call Trace: kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120 kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140 kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8 kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8 kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0 kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8 kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8 kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590 kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0 kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0 kernel: ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26960 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: swap: fix race between free_swap_and_cache() and swapoff()There was previously a theoretical window where swapoff() could run andteardown a swap_info_struct while a call to free_swap_and_cache() wasrunning in another thread. This could cause, amongst other badpossibilities, swap_page_trans_huge_swapped() (called byfree_swap_and_cache()) to access the freed memory for swap_map.This is a theoretical problem and I haven't been able to provoke it from atest case. But there has been agreement based on code review that this ispossible (see link below).Fix it by using get_swap_device()/put_swap_device(), which will stallswapoff(). There was an extra check in _swap_info_get() to confirm thatthe swap entry was not free. This isn't present in get_swap_device()because it doesn't make sense in general due to the race between gettingthe reference and swapoff. So I've added an equivalent check directly infree_swap_and_cache().Details of how to provoke one possible issue (thanks to David Hildenbrandfor deriving this):--8<-----__swap_entry_free() might be the last user and result in"count == SWAP_HAS_CACHE".swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.So the question is: could someone reclaim the folio and turnsi->inuse_pages==0, before we completed swap_page_trans_huge_swapped().Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages arestill references by swap entries.Process 1 still references subpage 0 via swap entry.Process 2 still references subpage 1 via swap entry.Process 1 quits. Calls free_swap_and_cache().-> count == SWAP_HAS_CACHE[then, preempted in the hypervisor etc.]Process 2 quits. Calls free_swap_and_cache().-> count == SWAP_HAS_CACHEProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls__try_to_reclaim_swap().__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()->put_swap_folio()->free_swap_slot()->swapcache_free_entries()->swap_entry_free()->swap_range_free()->...WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);What stops swapoff to succeed after process 2 reclaimed the swap cachebut before process1 finished its call to swap_page_trans_huge_swapped()?--8<-----

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26962 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshapeFor raid456, if reshape is still in progress, then IO across reshapeposition will wait for reshape to make progress. However, for dm-raid,in following cases reshape will never make progress hence IO will hang:1) the array is read-only;2) MD_RECOVERY_WAIT is set;3) MD_RECOVERY_FROZEN is set;After commit c467e97f079f ("md/raid6: use valid sector values to determineif an I/O should wait on the reshape") fix the problem that IO acrossreshape position doesn't wait for reshape, the dm-raid testshell/lvconvert-raid-reshape.sh start to hang:[root@fedora ~]# cat /proc/979/stack[<0>] wait_woken+0x7d/0x90[<0>] raid5_make_request+0x929/0x1d70 [raid456][<0>] md_handle_request+0xc2/0x3b0 [md_mod][<0>] raid_map+0x2c/0x50 [dm_raid][<0>] __map_bio+0x251/0x380 [dm_mod][<0>] dm_submit_bio+0x1f0/0x760 [dm_mod][<0>] __submit_bio+0xc2/0x1c0[<0>] submit_bio_noacct_nocheck+0x17f/0x450[<0>] submit_bio_noacct+0x2bc/0x780[<0>] submit_bio+0x70/0xc0[<0>] mpage_readahead+0x169/0x1f0[<0>] blkdev_readahead+0x18/0x30[<0>] read_pages+0x7c/0x3b0[<0>] page_cache_ra_unbounded+0x1ab/0x280[<0>] force_page_cache_ra+0x9e/0x130[<0>] page_cache_sync_ra+0x3b/0x110[<0>] filemap_get_pages+0x143/0xa30[<0>] filemap_read+0xdc/0x4b0[<0>] blkdev_read_iter+0x75/0x200[<0>] vfs_read+0x272/0x460[<0>] ksys_read+0x7a/0x170[<0>] __x64_sys_read+0x1c/0x30[<0>] do_syscall_64+0xc6/0x230[<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74This is because reshape can't make progress.For md/raid, the problem doesn't exist because register new sync_threaddoesn't rely on the IO to be done any more:1) If array is read-only, it can switch to read-write by ioctl/sysfs;2) md/raid never set MD_RECOVERY_WAIT;3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold 'reconfig_mutex', hence it can be cleared and reshape can continue by sysfs api 'sync_action'.However, I'm not sure yet how to avoid the problem in dm-raid yet. Thispatch on the one hand make sure raid_message() can't changesync_thread() through raid_message() after presuspend(), on the otherhand detect the above 3 cases before wait for IO do be done indm_suspend(), and let dm-raid requeue those IO.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26965 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: qcom: mmcc-msm8974: fix terminating of frequency table arraysThe frequency table arrays are supposed to be terminated with anempty element. Add such entry to the end of the arrays where itis missing in order to avoid possible out-of-bound access whenthe table is traversed by functions like qcom_find_freq() orqcom_find_freq_floor().Only compile tested.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26969 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: qcom: gcc-ipq8074: fix terminating of frequency table arraysThe frequency table arrays are supposed to be terminated with anempty element. Add such entry to the end of the arrays where itis missing in order to avoid possible out-of-bound access whenthe table is traversed by functions like qcom_find_freq() orqcom_find_freq_floor().Only compile tested.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26973 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fat: fix uninitialized field in nostale filehandlesWhen fat_encode_fh_nostale() encodes file handle without a parent itstores only first 10 bytes of the file handle. However the length of thefile handle must be a multiple of 4 so the file handle is actually 12bytes long and the last two bytes remain uninitialized. This is notgreat at we potentially leak uninitialized information with the handleto userspace. Properly initialize the full handle length.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26974 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - resolve race condition during AER recoveryDuring the PCI AER system's error recovery process, the kernel drivermay encounter a race condition with freeing the reset_data structure'smemory. If the device restart will take more than 10 seconds the functionscheduling that restart will exit due to a timeout, and the reset_datastructure will be freed. However, this data structure is used forcompletion notification after the restart is completed, which leadsto a UAF bug.This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340To resolve this race condition, the memory associated to the containerof the work_struct is freed on the worker if the timeout expired,otherwise on the function that schedules the worker.The timeout detection can be done by checking if the caller isstill waiting for completion or not by using completion_done() function.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-26982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check the inode number is not the invalid value of zeroSyskiller has produced an out of bounds access in fill_meta_index().That out of bounds access is ultimately caused because the inodehas an inode number with the invalid value of zero, which was not checked.The reason this causes the out of bounds access is due to followingsequence of events:1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.This patch adds a sanity check which checks that the inode numberis not zero when the inode is created and returns -EINVAL if it is.[phillip@squashfs.org.uk: whitespace fix]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: mediatek: Do a runtime PM get on controllers during probemt8183-mfgcfg has a mutual dependency with genpd during the probingstage, which leads to a deadlock in the following call stack:CPU0: genpd_lock --> clk_prepare_lockgenpd_power_off_work_fn() genpd_lock() generic_pm_domain::power_off() clk_unprepare() clk_prepare_lock()CPU1: clk_prepare_lock --> genpd_lockclk_register() __clk_core_init() clk_prepare_lock() clk_pm_runtime_get() genpd_lock()Do a runtime PM get at the probe function to make sure clk_register()won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg,do this on all mediatek clock controller probings because we don'tbelieve this would cause any regression.Verified on MT8183 and MT8192 Chromebooks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27010 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Fix mirred deadlock on device recursionWhen the mirred action is used on a classful egress qdisc and a packet ismirrored or redirected to self we hit a qdisc lock deadlock.See trace below.[..... other info removed for brevity....][ 82.890906][ 82.890906] ============================================[ 82.890906] WARNING: possible recursive locking detected[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W[ 82.890906] --------------------------------------------[ 82.890906] ping/418 is trying to acquire lock:[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:__dev_queue_xmit+0x1778/0x3550[ 82.890906][ 82.890906] but task is already holding lock:[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:__dev_queue_xmit+0x1778/0x3550[ 82.890906][ 82.890906] other info that might help us debug this:[ 82.890906] Possible unsafe locking scenario:[ 82.890906][ 82.890906] CPU0[ 82.890906] ----[ 82.890906] lock(&sch->q.lock);[ 82.890906] lock(&sch->q.lock);[ 82.890906][ 82.890906] *** DEADLOCK ***[ 82.890906][..... other info removed for brevity....]Example setup (eth0->eth0) to recreatetc qdisc add dev eth0 root handle 1: htb default 30tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0Another example(eth0->eth1->eth0) to recreatetc qdisc add dev eth0 root handle 1: htb default 30tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1tc qdisc add dev eth1 root handle 1: htb default 30tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0We fix this by adding an owner field (CPU id) to struct Qdisc set afterroot qdisc is entered. When the softirq enters it a second time, if theqdisc owner is the same CPU, the packet is dropped to break the loop.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27011 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix memleak in map from abort pathThe delete set command does not rely on the transaction object forelement removal, therefore, a combination of delete element + delete setfrom the abort path could result in restoring twice the refcount of themapping.Check for inactive element in the next generation for the delete elementcommand in the abort path, skip restoring state if next generation bithas been already cleared. This is similar to the activate logic usingthe set walk iterator.[ 6170.286929] ------------[ cut here ]------------[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.287071] Modules linked in: [...][ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100[ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000[ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0[ 6170.287962] Call Trace:[ 6170.287967] [ 6170.287973] ? __warn+0x9f/0x1a0[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.288092] ? report_bug+0x1b1/0x1e0[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.288092] ? report_bug+0x1b1/0x1e0[ 6170.288104] ? handle_bug+0x3c/0x70[ 6170.288112] ? exc_invalid_op+0x17/0x40[ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20[ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables][ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables][ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tun: limit printing rate when illegal packet received by tun devvhost_worker will call tun call backs to receive packets. If too manyillegal packets arrives, tun_do_read will keep dumping packet contents.When console is enabled, it will costs much more cpu time to dumppacket and soft lockup will be detected.net_ratelimit mechanism can be used to limit the dumping rate.PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27014 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Prevent deadlock while disabling aRFSWhen disabling aRFS under the `priv->state_lock`, any scheduledaRFS works are canceled using the `cancel_work_sync` function,which waits for the work to end if it has already started.However, while waiting for the work handler, the handler willtry to acquire the `state_lock` which is already acquired.The worker acquires the lock to delete the rules if the stateis down, which is not the worker's responsibility sincedisabling aRFS deletes the rules.Add an aRFS state variable, which indicates whether the aRFS isenabled and prevent adding rules when the aRFS is disabled.Kernel log:======================================================WARNING: possible circular locking dependency detected6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I------------------------------------------------------ethtool/386089 is trying to acquire lock:ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0but task is already holding lock:ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4eother info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); *** DEADLOCK ***3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]stack backtrace:CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27015 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: incorrect pppoe tuplepppoe traffic reaching ingress path does not match the flowtable entrybecause the pppoe header is expected to be at the network header offset.This bug causes a mismatch in the flow table lookup, so pppoe packetsenter the classical forwarding path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27016 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: validate pppoe headerEnsure there is sufficient room to access the protocol field of thePPPoe header. Validate it once before the flowtable lookup, then use ahelper function to access protocol field.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27019 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()nft_unregister_obj() can concurrent with __nft_obj_type_get(),and there is not any protection when iterate over nf_tables_objectslist in __nft_obj_type_get(). Therefore, there is potential data-raceof nf_tables_objects list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_objectslist in __nft_obj_type_get(), and use rcu_read_lock() in the callernft_obj_type_get() to protect the entire type query process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27020 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()nft_unregister_expr() can concurrent with __nft_expr_type_get(),and there is not any protection when iterate over nf_tables_expressionslist in __nft_expr_type_get(). Therefore, there is potential data-raceof nf_tables_expressions list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_expressionslist in __nft_expr_type_get(), and use rcu_read_lock() in the callernft_expr_type_get() to protect the entire type query process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27038 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: Fix clk_core_get NULL dereferenceIt is possible for clk_core_get to dereference a NULL in the followingsequence:clk_core_get() of_clk_get_hw_from_clkspec() __of_clk_get_hw_from_provider() __clk_get_hw()__clk_get_hw() can return NULL which is dereferenced by clk_core_get() athw->core.Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev basedclk_lookups") the check IS_ERR_OR_NULL() was performed which would havecaught the NULL.Reading the description of this function it talks about returning NULL butthat cannot be so at the moment.Update the function to check for hw before dereferencing it and return NULLif hw is NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27041 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini()Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULLbefore the call to dc_enable_dmub_notifications(), checkbeforehand to ensure there will not be a possible NULL-ptr-derefthere.Also, since commit 1e88eb1b2c25 ("drm/amd/display: DropCONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy().Clean up by combining them all under one 'if'.Found by Linux Verification Center (linuxtesting.org) with staticanalysis tool SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27044 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'The 'stream' pointer is used in dcn10_set_output_transfer_func() beforethe check if 'stream' is NULL.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27046 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfp: flower: handle acti_netdevs allocation failureThe kmalloc_array() in nfp_fl_lag_do_work() will return null, ifthe physical memory has run out. As a result, if we dereferencethe acti_netdevs, the null pointer dereference bugs will happen.This patch adds a check to judge whether allocation failure occurs.If it happens, the delayed work will be rescheduled and try again.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27054 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/dasd: fix double module refcount decrementOnce the discipline is associated with the device, deleting the devicetakes care of decrementing the module's refcount. Doing it manually onthis error path causes refcount to artificially decrease on each errorwhile it should just stay the same.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27056 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: ensure offloading TID queue existsThe resume code path assumes that the TX queue for the offloading TIDhas been configured. At resume time it then tries to sync the writepointer as it may have been updated by the firmware.In the unusual event that no packets have been send on TID 0, the queuewill not have been allocated and this causes a crash. Fix this byensuring the queue exist at suspend time.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27062 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nouveau: lock the client object tree.It appears the client object tree has no locking unless I've missedsomething else. Fix races around adding/removing client objects,mostly vram bar mappings. 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau][ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007[ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000[ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 4562.099544] Call Trace:[ 4562.099555] [ 4562.099573] ? die_addr+0x36/0x90[ 4562.099583] ? exc_general_protection+0x246/0x4a0[ 4562.099593] ? asm_exc_general_protection+0x26/0x30[ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau][ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau][ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau][ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau][ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0[ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm][ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270[ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau][ 4562.100356] __do_fault+0x32/0x150[ 4562.100362] do_fault+0x7c/0x560[ 4562.100369] __handle_mm_fault+0x800/0xc10[ 4562.100382] handle_mm_fault+0x17c/0x3e0[ 4562.100388] do_user_addr_fault+0x208/0x860[ 4562.100395] exc_page_fault+0x7f/0x200[ 4562.100402] asm_exc_page_fault+0x26/0x30[ 4562.100412] RIP: 0033:0x9b9870[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[ 4562.100446] [ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast 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 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27065 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: do not compare internal table flags on updatesRestore skipping transaction if table update does not modify flags.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27072 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: usbtv: Remove useless locks in usbtv_video_free()Remove locks calls in usbtv_video_free() becauseare useless and may led to a deadlock as reported here:https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000Also remove usbtv_stop() call since it will be called whenunregistering the device.Before 'c838530d230b' this issue would only be noticed if youdisconnect while streaming and now it is noticeable even whendisconnecting while not streaming.[hverkuil: fix minor spelling mistake in log message]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27076 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx: csc/scaler: fix v4l2_ctrl_handler memory leakFree the memory allocated in v4l2_ctrl_handler_init on release.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27078 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-tpg: fix some memleaks in tpg_allocIn tpg_alloc, resources should be deallocated in each and everyerror-handling paths, since they are allocated in for statements.Otherwise there would be memleaks because tpg_free is called only whentpg_alloc return 0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27388 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: fix some memleaks in gssx_dec_option_arrayThe creds and oa->data need to be freed in the error-handling paths aftertheir allocation. So this patch add these deallocations in thecorresponding paths.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27393 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xen-netfront: Add missing skb_mark_for_recycleNotice that skb_mark_for_recycle() is introduced later than fixes tag incommit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").It is believed that fixes tag were missing a call to page_pool_release_page()between v5.9 to v5.14, after which is should have used skb_mark_for_recycle().Since v6.6 the call page_pool_release_page() were removed (incommit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()")and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch'net-page_pool-remove-page_pool_release_page'")).This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catchpage_pool memory leaks").

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27395 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: Fix Use-After-Free in ovs_ct_exitSince kfree_rcu, which is called in the hlist_for_each_entry_rcu traversalof ovs_ct_limit_exit, is not part of the RCU read critical section, itis possible that the RCU grace period will pass during the traversal andthe key will be free.To prevent this, it should be changed to hlist_for_each_entry_safe.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27396 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: gtp: Fix Use-After-Free in gtp_dellinkSince call_rcu, which is called in the hlist_for_each_entry_rcu traversalof gtp_dellink, is not part of the RCU read critical section, itis possible that the RCU grace period will pass during the traversal andthe key will be free.To prevent this, it should be changed to hlist_for_each_entry_safe.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27399 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeoutThere is a race condition between l2cap_chan_timeout() andl2cap_chan_del(). When we use l2cap_chan_del() to delete thechannel, the chan->conn will be set to null. But the conn couldbe dereferenced again in the mutex_lock() of l2cap_chan_timeout().As a result the null pointer dereference bug will happen. TheKASAN report triggered by POC is shown below:[ 472.074580] ==================================================================[ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0[ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7[ 472.075308][ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36[ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4[ 472.075308] Workqueue: events l2cap_chan_timeout[ 472.075308] Call Trace:[ 472.075308] [ 472.075308] dump_stack_lvl+0x137/0x1a0[ 472.075308] print_report+0x101/0x250[ 472.075308] ? __virt_addr_valid+0x77/0x160[ 472.075308] ? mutex_lock+0x68/0xc0[ 472.075308] kasan_report+0x139/0x170[ 472.075308] ? mutex_lock+0x68/0xc0[ 472.075308] kasan_check_range+0x2c3/0x2e0[ 472.075308] mutex_lock+0x68/0xc0[ 472.075308] l2cap_chan_timeout+0x181/0x300[ 472.075308] process_one_work+0x5d2/0xe00[ 472.075308] worker_thread+0xe1d/0x1660[ 472.075308] ? pr_cont_work+0x5e0/0x5e0[ 472.075308] kthread+0x2b7/0x350[ 472.075308] ? pr_cont_work+0x5e0/0x5e0[ 472.075308] ? kthread_blkcg+0xd0/0xd0[ 472.075308] ret_from_fork+0x4d/0x80[ 472.075308] ? kthread_blkcg+0xd0/0xd0[ 472.075308] ret_from_fork_asm+0x11/0x20[ 472.075308] [ 472.075308] ==================================================================[ 472.094860] Disabling lock debugging due to kernel taint[ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158[ 472.096136] #PF: supervisor write access in kernel mode[ 472.096136] #PF: error_code(0x0002) - not-present page[ 472.096136] PGD 0 P4D 0[ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI[ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36[ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4[ 472.096136] Workqueue: events l2cap_chan_timeout[ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0[ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88[ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246[ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865[ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78[ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f[ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000[ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00[ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000[ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0[ 472.096136] Call Trace:[ 472.096136] [ 472.096136] ? __die_body+0x8d/0xe0[ 472.096136] ? page_fault_oops+0x6b8/0x9a0[ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0[ 472.096136] ? do_user_addr_fault+0x1027/0x1340[ 472.096136] ? _printk+0x7a/0xa0[ 472.096136] ? mutex_lock+0x68/0xc0[ 472.096136] ? add_taint+0x42/0xd0[ 472.096136] ? exc_page_fault+0x6a/0x1b0[ 472.096136] ? asm_exc_page_fault+0x26/0x30[ 472.096136] ? mutex_lock+0x75/0xc0[ 472.096136] ? mutex_lock+0x88/0xc0[ 472.096136] ? mutex_lock+0x75/0xc0[ 472.096136] l2cap_chan_timeo---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27403 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_flow_offload: reset dst in route object after setting up flowdst is transferred to the flow object, route object does not own itanymore. Reset dst in route object, otherwise if flow_offload_add()fails, error path releases dst twice, leading to a refcount underflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27416 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUESTIf we received HCI_EV_IO_CAPA_REQUEST whileHCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remotedoes support SSP since otherwise this event shouldn't be generated.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27435 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme: fix reconnection fail due to reserved tag allocationWe found a issue on production environment while using NVMe over RDMA,admin_q reconnect failed forever while remote target and network is ok.After dig into it, we found it may caused by a ABBA deadlock due to tagallocation. In my case, the tag was hold by a keep alive requestwaiting inside admin_q, as we quiesced admin_q while reset ctrl, so therequest maked as idle and will not process before reset success. Asfabric_q shares tagset with admin_q, while reconnect remote target, weneed a tag for connect command, but the only one reserved tag was heldby keep alive command which waiting inside admin_q. As a result, wefailed to reconnect admin_q forever. In order to fix this issue, Ithink we should keep two reserved tags for admin queue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-27436 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Stop parsing channels bits when all channels are found.If a usb audio device sets more bits than the amount of channelsit could write outside of the map array.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-33621 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outboundRaw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device willhit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helperCPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:sk_mc_loop+0x2d/0x70Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1cRSP: 0018:ffffa9584015cd78 EFLAGS: 00010212RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1)) ? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222) ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev.c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)The warning triggers as this:packet_sendmsg packet_snd //skb->sk is packet sk __dev_queue_xmit __dev_xmit_skb //q->enqueue is not NULL __qdisc_run sch_direct_xmit dev_hard_start_xmit ipvlan_start_xmit ipvlan_xmit_mode_l3 //l3 mode ipvlan_process_outbound //vepa flag ipvlan_process_v6_outbound ip6_local_out __ip6_finish_output ip6_finish_output2 //multicast packet sk_mc_loop //sk->sk_family is AF_PACKETCall ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35247 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fpga: region: add owner module and take its refcountThe current implementation of the fpga region assumes that the low-levelmodule registers a driver for the parent device and uses its owner pointerto take the module's refcount. This approach is problematic since it canlead to a null pointer dereference while attempting to get the regionduring programming if the parent device does not have a driver.To address this problem, add a module owner pointer to the fpga_regionstruct and use it to take the module's refcount. Modify the functions forregistering a region to take an additional owner module parameter andrename them to avoid conflicts. Use the old function names for helpermacros that automatically set the module that registers the region as theowner. This ensures compatibility with existing low-level control modulesand reduces the chances of registering a region without setting the owner.Also, update the documentation to keep it consistent with the new interfacefor registering an fpga region.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35794 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm-raid: really frozen sync_thread during suspend1) commit f52f5c71f3d4 ("md: fix stopping sync thread") remove MD_RECOVERY_FROZEN from __md_stop_writes() and doesn't realize that dm-raid relies on __md_stop_writes() to frozen sync_thread indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in md_stop_writes(), and since stop_sync_thread() is only used for dm-raid in this case, also move stop_sync_thread() to md_stop_writes().2) The flag MD_RECOVERY_FROZEN doesn't mean that sync thread is frozen, it only prevent new sync_thread to start, and it can't stop the running sync thread; In order to frozen sync_thread, after seting the flag, stop_sync_thread() should be used.3) The flag MD_RECOVERY_FROZEN doesn't mean that writes are stopped, use it as condition for md_stop_writes() in raid_postsuspend() doesn't look correct. Consider that reentrant stop_sync_thread() do nothing, always call md_stop_writes() in raid_postsuspend().4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime, and if MD_RECOVERY_FROZEN is cleared while the array is suspended, new sync_thread can start unexpected. Fix this by disallow raid_message() to change sync_thread status during suspend.Note that after commit f52f5c71f3d4 ("md: fix stopping sync thread"), thetest shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(),and with previous fixes, the test won't hang there anymore, however, thetest will still fail and complain that ext4 is corrupted. And with thispatch, the test won't hang due to stop_sync_thread() or fail due to ext4is corrupted anymore. However, there is still a deadlock related todm-raid456 that will be fixed in following patches.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35796 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ll_temac: platform_get_resource replaced by wrong functionThe function platform_get_resource was replaced withdevm_platform_ioremap_resource_byname and is called using 0 as name.This eventually ends up in platform_get_resource_byname in the callstack, where it causes a null pointer in strcmp. if (type == resource_type(r) && !strcmp(r->name, name))It should have been replaced with devm_platform_ioremap_resource.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35801 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Keep xfd_state in sync with MSR_IA32_XFDCommit 672365477ae8 ("x86/fpu: Update XFD state where required") andcommit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced aper CPU variable xfd_state to keep the MSR_IA32_XFD value cached, inorder to avoid unnecessary writes to the MSR.On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, whichwipes out any stale state. But the per CPU cached xfd value is notreset, which brings them out of sync.As a consequence a subsequent xfd_update_state() might fail to updatethe MSR which in turn can result in XRSTOR raising a #NM in kernelspace, which crashes the kernel.To fix this, introduce xfd_set_state() to write xfd_state togetherwith MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35804 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Mark target gfn of emulated atomic instruction as dirtyWhen emulating an atomic access on behalf of the guest, mark the targetgfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. Thisfixes a bug where KVM effectively corrupts guest memory during livemigration by writing to guest memory without informing userspace that thepage is dirty.Marking the page dirty got unintentionally dropped when KVM's emulatedCMPXCHG was converted to do a user access. Before that, KVM explicitlymapped the guest page into kernel memory, and marked the page dirty duringthe unmap phase.Mark the page dirty even if the CMPXCHG fails, as the old data is writtenback on failure, i.e. the page is still written. The value written isguaranteed to be the same because the operation is atomic, but KVM's ABIis that all writes are dirty logged regardless of the value written. Andmore importantly, that's what KVM did before the buggy commit.Huge kudos to the folks on the Cc list (and many others), who did all theactual work of triaging and debugging.base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35805 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm snapshot: fix lockup in dm_exception_table_exitThere was reported lockup when we exit a snapshot with many exceptions.Fix this by adding "cond_resched" to the loop that frees the exceptions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35807 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix corruption during on-line resizeWe observed a corruption during on-line resize of a file system that islarger than 16 TiB with 4k block size. With having more then 2^32 blocksresize_inode is turned off by default by mke2fs. The issue can bereproduced on a smaller file system for convenience by explicitlyturning off resize_inode. An on-line resize across an 8 GiB boundary (thesize of a meta block group in this setup) then leads to a corruption: dev=/dev/ # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks perblock group and 2^6 are the number of block groups that make a metablock group.The last checksum might be different depending on how the file is laidout across the physical blocks. The actual corruption occurs at physicalblock 63*2^15 = 2064384 which would be the location of the backup of themeta block group's block descriptor. During the on-line resize the filesystem will be converted to meta_bg starting at s_first_meta_bg which is2 in the example - meaning all block groups after 16 GiB. However, inext4_flex_group_add we might add block groups that are not part of thefirst meta block group yet. In the reproducer we achieved this bysubstracting the size of a whole block group from the point where themeta block group would start. This must be considered when updating thebackup block group descriptors to follow the non-meta_bg layout. The fixis to add a test whether the group to add is already part of the metablock group or not.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35808 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/dm-raid: don't call md_reap_sync_thread() directlyCurrently md_reap_sync_thread() is called from raid_message() directlywithout holding 'reconfig_mutex', this is definitely unsafe becausemd_reap_sync_thread() can change many fields that is protected by'reconfig_mutex'.However, hold 'reconfig_mutex' here is still problematic because thiswill cause deadlock, for example, commit 130443d60b1b ("md: refactoridle/frozen_sync_thread() to fix deadlock").Fix this problem by using stop_sync_thread() to unregister sync_thread,like md/raid did.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35821 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ubifs: Set page uptodate in the correct placePage cache reads are lockless, so setting the freshly allocated pageuptodate before we've overwritten it with the data it's supposed to havein it will allow a simultaneous reader to see old data. Move the callto SetPageUptodate into ubifs_write_end(), which is after we copied thenew data into the page.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35823 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vt: fix unicode buffer corruption when deleting charactersThis is the same issue that was fixed for the VGA text buffer in commit39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in thebuffer"). The cure is also the same i.e. replace memcpy() with memmove()due to the overlaping buffers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35825 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: ncm: Fix handling of zero block length packetsWhile connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TXset to 65536, it has been observed that we receive short packets,which come at interval of 5-10 seconds sometimes and have blocklength zero but still contain 1-2 valid datagrams present.According to the NCM spec:"If wBlockLength = 0x0000, the block is terminated by ashort packet. In this case, the USB transfer must stillbe shorter than dwNtbInMaxSize or dwNtbOutMaxSize. Ifexactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent,and the size is a multiple of wMaxPacketSize for thegiven pipe, then no ZLP shall be sent.wBlockLength= 0x0000 must be used with extreme care, becauseof the possibility that the host and device may get out ofsync, and because of test issues.wBlockLength = 0x0000 allows the sender to reduce latency bystarting to send a very large NTB, and then shortening it whenthe sender discovers that there's not sufficient data to justifysending a large NTB"However, there is a potential issue with the current implementation,as it checks for the occurrence of multiple NTBs in a singlegiveback by verifying if the leftover bytes to be processed is zeroor not. If the block length reads zero, we would process the sameNTB infintely because the leftover bytes is never zero and it leadsto a crash. Fix this by bailing out if block length reads zero.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35829 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/lima: fix a memleak in lima_heap_allocWhen lima_vm_map_bo fails, the resources need to be deallocated, orthere will be memleaks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35830 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: tc358743: register v4l2 async device only after successful setupEnsure the device has been setup correctly before registering the v4l2async device, thus allowing userspace to access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35833 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMAThis dma_alloc_coherent() is undone neither in the remove function, nor inthe error handling path of fsl_qdma_probe().Switch to the managed version to fix both issues.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35837 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mvpp2: clear BM pool before initializationRegister value persist after booting the kernel usingkexec which results in kernel panic. Thus clear theBM pool registers before initialisation to fix the issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35845 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: dbg-tlv: ensure NUL terminationThe iwl_fw_ini_debug_info_tlv is used as a string, so we mustensure the string is terminated correctly before using it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35847 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3-its: Prevent double free on errorThe error handling path in its_vpe_irq_domain_alloc() causes a double freewhen its_vpe_init() fails after successfully allocating at least oneinterrupt. This happens because its_vpe_irq_domain_free() frees theinterrupts along with the area bitmap and the vprop_page andits_vpe_irq_domain_alloc() subsequently frees the area bitmap and thevprop_page again.Fix this by unconditionally invoking its_vpe_irq_domain_free() whichhandles all cases correctly and by removing the bitmap/vprop_page freeingfrom its_vpe_irq_domain_alloc().[ tglx: Massaged change log ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35848 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:eeprom: at24: fix memory corruption race conditionIf the eeprom is not accessible, an nvmem device will be registered, theread will fail, and the device will be torn down. If another driveraccesses the nvmem device after the teardown, it will referenceinvalid memory.Move the failure point before registering the nvmem device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35849 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix information leak in btrfs_ioctl_logical_to_ino()Syzbot reported the following information leak for inbtrfs_ioctl_logical_to_ino(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000This happens, because we're copying a 'struct btrfs_data_container' backto user-space. This btrfs_data_container is allocated in'init_data_container()' via kvmalloc(), which does not zero-fill thememory.Fix this by using kvzalloc() which zeroes out the memory on allocation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35851 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: qca: fix NULL-deref on non-serdev suspendQualcomm ROME controllers can be registered from the Bluetooth linediscipline and in this case the HCI UART serdev pointer is NULL.Add the missing sanity check to prevent a NULL-pointer dereference whenwakeup() is called for a non-serdev controller during suspend.Just return true for now to restore the original behaviour and addressthe crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657("Bluetooth: hci_qca: only assign wakeup with serial port support") thatcauses the crash to happen already at setup() time.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash workThe rehash delayed work is rescheduled with a delay if the number ofcredits at end of the work is not negative as supposedly it means thatthe migration ended. Otherwise, it is rescheduled immediately.After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free duringrehash" the above is no longer accurate as a non-negative number ofcredits is no longer indicative of the migration being done. It can alsohappen if the work encountered an error in which case the migration willresume the next time the work is scheduled.The significance of the above is that it is possible for the work to bepending and associated with hints that were allocated when the migrationstarted. This leads to the hints being leaked [1] when the work iscanceled while pending as part of ACL region dismantle.Fix by freeing the hints if hints are associated with a work that wascanceled while pending.Blame the original commit since the reliance on not having a pendingwork associated with hints is fragile.[1]unreferenced object 0xffff88810e7c3000 (size 256): comm "kworker/0:16", pid 176, jiffies 4295460353 hex dump (first 32 bytes): 00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80 .0......a....... 00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00 ..a.@........... backtrace (crc 2544ddb9): [<00000000cf8cfab3>] kmalloc_trace+0x23f/0x2a0 [<000000004d9a1ad9>] objagg_hints_get+0x42/0x390 [<000000000b143cf3>] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400 [<0000000059bdb60a>] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160 [<00000000e81fd734>] process_one_work+0x59c/0xf20 [<00000000ceee9e81>] worker_thread+0x799/0x12c0 [<00000000bda6fe39>] kthread+0x246/0x300 [<0000000070056d23>] ret_from_fork+0x34/0x70 [<00000000dea2b93e>] ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix memory leak during rehashThe rehash delayed work migrates filters from one region to another.This is done by iterating over all chunks (all the filters with the samepriority) in the region and in each chunk iterating over all thefilters.If the migration fails, the code tries to migrate the filters back tothe old region. However, the rollback itself can also fail in which caseanother migration will be erroneously performed. Besides the fact thatthis ping pong is not a very good idea, it also creates a problem.Each virtual chunk references two chunks: The currently used one('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration thefirst holds the chunk we want to migrate filters to and the second holdsthe chunk we are migrating filters from.The code currently assumes - but does not verify - that the backup chunkdoes not exist (NULL) if the currently used chunk does not reference thetarget region. This assumption breaks when we are trying to rollback arollback, resulting in the backup chunk being overwritten and leaked[1].Fix by not rolling back a failed rollback and add a warning to avoidfuture cases.[1]WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20Modules linked in:CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_workRIP: 0010:parman_destroy+0x17/0x20[...]Call Trace: mlxsw_sp_acl_atcam_region_fini+0x19/0x60 mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35854 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehashThe rehash delayed work migrates filters from one region to anotheraccording to the number of available credits.The migrated from region is destroyed at the end of the work if thenumber of credits is non-negative as the assumption is that this isindicative of migration being complete. This assumption is incorrect asa non-negative number of credits can also be the result of a failedmigration.The destruction of a region that still has filters referencing it canresult in a use-after-free [1].Fix by not destroying the region if migration failed.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_workCall Trace: dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70 mlxsw_sp_acl_atcam_entry_del+0x81/0x210 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Allocated by task 174: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30Freed by task 7: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_region_destroy+0x272/0x310 mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity updateThe rule activity update delayed work periodically traverses the list ofconfigured rules and queries their activity from the device.As part of this task it accesses the entry pointed by 'ventry->entry',but this entry can be changed concurrently by the rehash delayed work,leading to a use-after-free [1].Fix by closing the race and perform the activity query under the'vregion->lock' mutex.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_workCall Trace: dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 mlxsw_sp_acl_rule_activity_update_work+0x219/0x400 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Allocated by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30Freed by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:icmp: prevent possible NULL dereferences from icmp_build_probe()First problem is a double call to __in_dev_get_rcu(), becausethe second one could return NULL.if (__in_dev_get_rcu(dev) && __in_dev_get_rcu(dev)->ifa_list)Second problem is a read from dev->ip6_ptr with no NULL check:if (!list_empty(&rcu_dereference(dev->ip6_ptr)->addr_list))Use the correct RCU API to fix these.v2: add missing include

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35866 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in cifs_dump_full_key()Skip sessions that are being teared down (status == SES_EXITING) toavoid UAF.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35870 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix UAF in smb2_reconnect_server()The UAF bug is due to smb2_reconnect_server() accessing a session thatis already being teared down by another thread that is executing__cifs_put_smb_ses(). This can happen when (a) the client hasconnection to the server but no session or (b) another thread ends upsetting @ses->ses_status again to something different thanSES_EXITING.To fix this, we need to make sure to unconditionally set@ses->ses_status to SES_EXITING and prevent any other threads fromsetting a new status while we're still tearing it down.The following can be reproduced by adding some delay to right afterthe ipc is freed in __cifs_put_smb_ses() - which will givesmb2_reconnect_server() worker a chance to run and then accessing@ses->ipc:kinit ...mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10[disconnect srv]ls /mnt/1 &>/dev/nullsleep 30kdestroy[reconnect srv]sleep 10umount /mnt/1...CIFS: VFS: Verify user has a krb5 ticket and keyutils is installedCIFS: VFS: \\srv Send error in SessSetup = -126CIFS: VFS: Verify user has a krb5 ticket and keyutils is installedCIFS: VFS: \\srv Send error in SessSetup = -126general protection fault, probably for non-canonical address0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTICPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc3904/01/2014Workqueue: cifsiod smb2_reconnect_server [cifs]RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 adde 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 757b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6bRDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000FS: 0000000000000000(0000) GS:ffff888157c00000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0PKRU: 55555554Call Trace: ? die_addr+0x36/0x90 ? exc_general_protection+0x1c1/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? __list_del_entry_valid_or_report+0x33/0xf0 __cifs_put_smb_ses+0x1ae/0x500 [cifs] smb2_reconnect_server+0x4ed/0x710 [cifs] process_one_work+0x205/0x6b0 worker_thread+0x191/0x360 ? __pfx_worker_thread+0x10/0x10 kthread+0xe2/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35872 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/secretmem: fix GUP-fast succeeding on secretmem foliosfolio_is_secretmem() currently relies on secretmem folios being LRUfolios, to save some cycles.However, folios might reside in a folio batch without the LRU flag set, ortemporarily have their LRU flag cleared. Consequently, the LRU flag isunreliable for this purpose.In particular, this is the case when secretmem_fault() allocates a freshpage and calls filemap_add_folio()->folio_add_lru(). The folio might beadded to the per-cpu folio batch and won't get the LRU flag set until thebatch was drained using e.g., lru_add_drain().Consequently, folio_is_secretmem() might not detect secretmem folios andGUP-fast can succeed in grabbing a secretmem folio, crashing the kernelwhen we would later try reading/writing to the folio, because the foliohas been unmapped from the directmap.Fix it by removing that unreliable check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35877 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mm/pat: fix VM_PAT handling in COW mappingsPAT handling won't do the right thing in COW mappings: the first PTE (or,in fact, all PTEs) can be replaced during write faults to point at anonfolios. Reliably recovering the correct PFN and cachemode usingfollow_phys() from PTEs will not work in COW mappings.Using follow_phys(), we might just get the address+protection of the anonfolio (which is very wrong), or fail on swap/nonswap entries, failingfollow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() andtrack_pfn_copy(), not properly calling free_pfn_range().In free_pfn_range(), we either wouldn't call memtype_free() or would callit with the wrong range, possibly leaking memory.To fix that, let's update follow_phys() to refuse returning anon folios,and fallback to using the stored PFN inside vma->vm_pgoff for COW mappingsif we run into that.We will now properly handle untrack_pfn() with COW mappings, where wedon't need the cachemode. We'll have to fail fork()->track_pfn_copy() ifthe first page was replaced by an anon folio, though: we'd have to storethe cachemode in the VMA to make this work, likely growing the VMA size.For now, lets keep it simple and let track_pfn_copy() just fail in thatcase: it would have failed in the past with swap/nonswap entries already,and it would have done the wrong thing with anon folios.Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():<--- C reproducer ---> #include #include #include #include int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map; ring_fd = io_uring_setup(1, &p); if (ring_fd < 0) { perror("io_uring_setup"); return 1; } size = p.sq_off.array + p.sq_entries * sizeof(unsigned); /* Map the submission queue ring MAP_PRIVATE */ map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, ring_fd, IORING_OFF_SQ_RING); if (map == MAP_FAILED) { perror("mmap"); return 1; } /* We have at least one page. Let's COW it. */ *map = 0; pause(); return 0; }<--- C reproducer --->On a system with 16 GiB RAM and swap configured: # ./iouring & # memhog 16G # killall iouring[ 301.552930] ------------[ cut here ]------------[ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100[ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g[ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1[ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4[ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100[ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000[ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282[ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047[ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200[ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000[ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000[ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000[ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000[ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0[ 301.565725] PKRU: 55555554[ 301.565944] Call Trace:[ 301.566148] [ 301.566325] ? untrack_pfn+0xf4/0x100[ 301.566618] ? __warn+0x81/0x130[ 301.566876] ? untrack_pfn+0xf4/0x100[ 3---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35879 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:of: dynamic: Synchronize of_changeset_destroy() with the devlink removalsIn the following sequence: 1) of_platform_depopulate() 2) of_overlay_remove()During the step 1, devices are destroyed and devlinks are removed.During the step 2, OF nodes are destroyed but__of_changeset_entry_destroy() can raise warnings related to missingof_node_put(): ERROR: memory leak, expected refcount 1 instead of 2 ...Indeed, during the devlink removals performed at step 1, the removalitself releasing the device (and the attached of_node) is done by a jobqueued in a workqueue and so, it is done asynchronously with respect tofunction calls.When the warning is present, of_node_put() will be called but wronglytoo late from the workqueue job.In order to be sure that any ongoing devlink removals are done beforethe of_node destruction, synchronize the of_changeset_destroy() with thedevlink removals.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35884 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udp: do not accept non-tunnel GSO skbs landing in a tunnelWhen rx-udp-gro-forwarding is enabled UDP packets might be GROed whenbeing forwarded. If such packets might land in a tunnel this can causevarious issues and udp_gro_receive makes sure this isn't the case bylooking for a matching socket. This is performed inudp4/6_gro_lookup_skb but only in the current netns. This is an issuewith tunneled packets when the endpoint is in another netns. In suchcases the packets will be GROed at the UDP level, which leads to variousissues later on. The same thing can happen with rx-gro-list.We saw this with geneve packets being GROed at the UDP level. In suchcase gso_size is set; later the packet goes through the geneve rx path,the geneve header is pulled, the offset are adjusted and frag_list skbsare not adjusted with regard to geneve. When those skbs hitskb_fragment, it will misbehave. Different outcomes are possibledepending on what the GROed skbs look like; from corrupted packets tokernel crashes.One example is a BUG_ON[1] triggered in skb_segment while processing thefrag_list. Because gso_size is wrong (geneve header was pulled)skb_segment thinks there is "geneve header size" of data in frag_list,although it's in fact the next packet. The BUG_ON itself has nothing todo with the issue. This is only one of the potential issues.Looking up for a matching socket in udp_gro_receive is fragile: thelookup could be extended to all netns (not speaking about performances)but nothing prevents those packets from being modified in between and wecould still not find a matching socket. It's OK to keep the currentlogic there as it should cover most cases but we also need to make surewe handle tunnel packets being GROed too early.This is done by extending the checks in udp_unexpected_gso: GSO packetslacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel mustbe segmented.[1] kernel BUG at net/core/skbuff.c:4408! RIP: 0010:skb_segment+0xd2a/0xf70 __udp_gso_segment+0xaa/0x560

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35885 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxbf_gige: stop interface during shutdownThe mlxbf_gige driver intermittantly encounters a NULL pointerexception while the system is shutting down via "reboot" command.The mlxbf_driver will experience an exception right after executingits shutdown() method. One example of this exception is:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation faultData abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000[0000000000000070] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 96000004 [#1] SMPCPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S OE 5.15.0-bf.6.gef6992a #1Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]lr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]sp : ffff8000080d3c10x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58x26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128x20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffffx17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101x11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404x8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080x5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000Call trace: mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] __napi_poll+0x40/0x1c8 net_rx_action+0x314/0x3a0 __do_softirq+0x128/0x334 run_ksoftirqd+0x54/0x6c smpboot_thread_fn+0x14c/0x190 kthread+0x10c/0x110 ret_from_fork+0x10/0x20Code: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002)---[ end trace 7cc3941aa0d8e6a4 ]---Kernel panic - not syncing: Oops: Fatal exception in interruptKernel Offset: 0x4ce722520000 from 0xffff800008000000PHYS_OFFSET: 0x80000000CPU features: 0x000005c1,a3330e5aMemory Limit: none---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---During system shutdown, the mlxbf_gige driver's shutdown() is always executed.However, the driver's stop() method will only execute if networking interfaceconfiguration logic within the Linux distribution has been setup to do so.If shutdown() executes but stop() does not execute, NAPI remains enabledand this can lead to an exception if NAPI is scheduled while the hardwareinterface has only been partially deinitialized.The networking interface managed by the mlxbf_gige driver must be properlystopped during system shutdown so that IFF_UP is cleared, the hardwareinterface is put into a clean state, and NAPI is fully deinitialized.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35887 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: fix use-after-free bugs caused by ax25_ds_del_timerWhen the ax25 device is detaching, the ax25_dev_device_down()calls ax25_ds_del_timer() to cleanup the slave_timer. Whenthe timer handler is running, the ax25_ds_del_timer() thatcalls del_timer() in it will return directly. As a result,the use-after-free bugs could happen, one of the scenariosis shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout()ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USEIn order to mitigate bugs, when the device is detaching, usetimer_shutdown_sync() to stop the timer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35888 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erspan: make sure erspan_base_hdr is present in skb->headsyzbot reported a problem in ip6erspan_rcv() [1]Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer makesure erspan_base_hdr is present in skb linear part (skb->head)before getting @ver field from it.Add the missing pskb_may_pull() calls.v2: Reload iph pointer in erspan_rcv() after pskb_may_pull() because skb->head might have changed.[1] BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline] BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] pskb_may_pull include/linux/skbuff.h:2756 [inline] ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5538 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652 netif_receive_skb_internal net/core/dev.c:5738 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5798 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549 tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 tun_alloc_skb drivers/net/tun.c:1525 [inline] tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35893 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_skbmod: prevent kernel-infoleaksyzbot found that tcf_skbmod_dump() was copying four bytesfrom kernel stack to user space [1].The issue here is that 'struct tc_skbmod' has a four bytes hole.We need to clear the structure before filling fields.[1]BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] simple_copy_to_iter net/core/datagram.c:532 [inline] __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline] netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242 __do_sys_recvfrom net/socket.c:2260 [inline] __se_sys_recvfrom net/socket.c:2256 [inline] __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was stored to memory at: pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253 netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317 netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351 nlmsg_unicast include/net/netlink.h:1144 [inline] nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610 rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741 rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline] tcf_add_notify net/sched/act_api.c:2048 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was stored to memory at: __nla_put lib/nlattr.c:1041 [inline] nla_put+0x1c6/0x230 lib/nlattr.c:1099 tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256 tcf_action_dump_old net/sched/act_api.c:1191 [inline] tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227 tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251 tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628 tcf_add_notify_msg net/sched/act_api.c:2023 [inline] tcf_add_notify net/sched/act_api.c:2042 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netli---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35897 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: discard table flag update with pending basechain deletionHook unregistration is deferred to the commit phase, same occurs withhook updates triggered by the table dormant flag. When both commands arecombined, this results in deleting a basechain while leaving its hookstill registered in the core.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35898 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()nft_unregister_flowtable_type() within nf_flow_inet_module_exit() canconcurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().And thhere is not any protection when iterate over nf_tables_flowtableslist in __nft_flowtable_type_get(). Therefore, there is pertentialdata-race of nf_tables_flowtables list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables listin __nft_flowtable_type_get(), and use rcu_read_lock() in the callernft_flowtable_type_get() to protect the entire type query process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: flush pending destroy work before exit_net releaseSimilar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroywork before netlink notifier") to address a race between exit_net andthe destroy workqueue.The trace below shows an element to be released via destroy workqueuewhile exit_net path (triggered via module removal) has already releasedthe set that is used in such transaction.[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables][ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465[ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359[ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables][ 1360.547984] Call Trace:[ 1360.547991] [ 1360.547998] dump_stack_lvl+0x53/0x70[ 1360.548014] print_report+0xc4/0x610[ 1360.548026] ? __virt_addr_valid+0xba/0x160[ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10[ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables][ 1360.548176] kasan_report+0xae/0xe0[ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables][ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables][ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables][ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30[ 1360.548591] process_one_work+0x2f1/0x670[ 1360.548610] worker_thread+0x4d3/0x760[ 1360.548627] ? __pfx_worker_thread+0x10/0x10[ 1360.548640] kthread+0x16b/0x1b0[ 1360.548653] ? __pfx_kthread+0x10/0x10[ 1360.548665] ret_from_fork+0x2f/0x50[ 1360.548679] ? __pfx_kthread+0x10/0x10[ 1360.548690] ret_from_fork_asm+0x1a/0x30[ 1360.548707] [ 1360.548719] Allocated by task 192061:[ 1360.548726] kasan_save_stack+0x20/0x40[ 1360.548739] kasan_save_track+0x14/0x30[ 1360.548750] __kasan_kmalloc+0x8f/0xa0[ 1360.548760] __kmalloc_node+0x1f1/0x450[ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables][ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink][ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink][ 1360.548927] netlink_unicast+0x367/0x4f0[ 1360.548935] netlink_sendmsg+0x34b/0x610[ 1360.548944] ____sys_sendmsg+0x4d4/0x510[ 1360.548953] ___sys_sendmsg+0xc9/0x120[ 1360.548961] __sys_sendmsg+0xbe/0x140[ 1360.548971] do_syscall_64+0x55/0x120[ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d[ 1360.548994] Freed by task 192222:[ 1360.548999] kasan_save_stack+0x20/0x40[ 1360.549009] kasan_save_track+0x14/0x30[ 1360.549019] kasan_save_free_info+0x3b/0x60[ 1360.549028] poison_slab_object+0x100/0x180[ 1360.549036] __kasan_slab_free+0x14/0x30[ 1360.549042] kfree+0xb6/0x260[ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables][ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables][ 1360.549221] ops_exit_list+0x50/0xa0[ 1360.549229] free_exit_list+0x101/0x140[ 1360.549236] unregister_pernet_operations+0x107/0x160[ 1360.549245] unregister_pernet_subsys+0x1c/0x30[ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables][ 1360.549345] __do_sys_delete_module+0x253/0x370[ 1360.549352] do_syscall_64+0x55/0x120[ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d(gdb) list *__nft_release_table+0x4730x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) {11350 list_del(&flowtable->list);11351 nft_use_dec(&table->use);11352 nf_tables_flowtable_destroy(flowtable);11353 }11354 list_for_each_entry_safe(set, ns, &table->sets, list) {11355 list_del(&set->list);11356 nft_use_dec(&table->use);11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT))11358 nft_map_deactivat---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35900 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: reject new basechain after table flag updateWhen dormant flag is toggled, hooks are disabled in the commit phase byiterating over current chains in table (existing and new).The following configuration allows for an inconsistent state: add table x add chain x y { type filter hook input priority 0; } add table x { flags dormant; } add chain x w { type filter hook input priority 1; }which triggers the following warning when trying to unregister chain wwhich is already unregistered.[ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260[...][ 127.322519] Call Trace:[ 127.322521] [ 127.322524] ? __warn+0x9f/0x1a0[ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260[ 127.322537] ? report_bug+0x1b1/0x1e0[ 127.322545] ? handle_bug+0x3c/0x70[ 127.322552] ? exc_invalid_op+0x17/0x40[ 127.322556] ? asm_exc_invalid_op+0x1a/0x20[ 127.322563] ? kasan_save_free_info+0x3b/0x60[ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260[ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260[ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260[ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables][ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables][ 127.322717] nf_tables_commit+0x2571/0x2620 [nf_tables]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35907 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxbf_gige: call request_irq() after NAPI initializedThe mlxbf_gige driver encounters a NULL pointer exception inmlxbf_gige_open() when kdump is enabled. The sequence to reproducethe exception is as follows:a) enable kdumpb) trigger kdump via "echo c > /proc/sysrq-trigger"c) kdump kernel executesd) kdump kernel loads mlxbf_gige modulee) the mlxbf_gige module runs its open() as the the "oob_net0" interface is brought upf) mlxbf_gige module will experience an exception during its open(), something like: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000004 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e29a4000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000086000004 [#1] SMP CPU: 0 PID: 812 Comm: NetworkManager Tainted: G OE 5.15.0-1035-bluefield #37-Ubuntu Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.6.0.13024 Jan 19 2024 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : __napi_poll+0x40/0x230 sp : ffff800008003e00 x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff x26: ffff000066027238 x25: ffff00007cedec00 x24: ffff800008003ec8 x23: 000000000000012c x22: ffff800008003eb7 x21: 0000000000000000 x20: 0000000000000001 x19: ffff000066027238 x18: 0000000000000000 x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0 x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa870b0842398 x8 : 0000000000000004 x7 : fe5a48b9069706ea x6 : 17fdb11fc84ae0d2 x5 : d94a82549d594f35 x4 : 0000000000000000 x3 : 0000000000400100 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000066027238 Call trace: 0x0 net_rx_action+0x178/0x360 __do_softirq+0x15c/0x428 __irq_exit_rcu+0xac/0xec irq_exit+0x18/0x2c handle_domain_irq+0x6c/0xa0 gic_handle_irq+0xec/0x1b0 call_on_irq_stack+0x20/0x2c do_interrupt_handler+0x5c/0x70 el1_interrupt+0x30/0x50 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x7c/0x80 __setup_irq+0x4c0/0x950 request_threaded_irq+0xf4/0x1bc mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige] mlxbf_gige_open+0x5c/0x170 [mlxbf_gige] __dev_open+0x100/0x220 __dev_change_flags+0x16c/0x1f0 dev_change_flags+0x2c/0x70 do_setlink+0x220/0xa40 __rtnl_newlink+0x56c/0x8a0 rtnl_newlink+0x58/0x84 rtnetlink_rcv_msg+0x138/0x3c4 netlink_rcv_skb+0x64/0x130 rtnetlink_rcv+0x20/0x30 netlink_unicast+0x2ec/0x360 netlink_sendmsg+0x278/0x490 __sock_sendmsg+0x5c/0x6c ____sys_sendmsg+0x290/0x2d4 ___sys_sendmsg+0x84/0xd0 __sys_sendmsg+0x70/0xd0 __arm64_sys_sendmsg+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 Code: bad PC value ---[ end trace 7d1c3f3bf9d81885 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Kernel Offset: 0x2870a7a00000 from 0xffff800008000000 PHYS_OFFSET: 0x80000000 CPU features: 0x0,000005c1,a3332a5a Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---The exception happens because there is a pending RX interrupt before thecall to request_irq(RX IRQ) executes. Then, the RX IRQ handler firesimmediately after this request_irq() completes. The---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35910 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: properly terminate timers for kernel socketsWe had various syzbot reports about tcp timers firing afterthe corresponding netns has been dismantled.Fortunately Josef Bacik could trigger the issue more often,and could test a patch I wrote two years ago.When TCP sockets are closed, we call inet_csk_clear_xmit_timers()to 'stop' the timers.inet_csk_clear_xmit_timers() can be called from any context,including when socket lock is held.This is the reason it uses sk_stop_timer(), aka del_timer().This means that ongoing timers might finish much later.For user sockets, this is fine because each running timerholds a reference on the socket, and the user socket holdsa reference on the netns.For kernel sockets, we risk that the netns is freed beforetimer can complete, because kernel sockets do not holdreference on the netns.This patch adds inet_csk_clear_xmit_timers_sync() functionthat using sk_stop_timer_sync() to make sure all timersare terminated before the kernel socket is released.Modules using kernel sockets close them in their netns exit()handler.Also add sock_not_owned_by_me() helper to get LOCKDEPsupport : inet_csk_clear_xmit_timers_sync() must not be calledwhile socket lock is held.It is very possible we can revert in the future commit3a58f13a881e ("net: rds: acquire refcount on TCP sockets")which attempted to solve the issue in rds only.(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)We probably can remove the check_net() tests fromtcp_out_of_resources() and __tcp_close() in the future.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35915 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packetsyzbot reported the following uninit-value access issue [1][2]:nci_rx_work() parses and processes received packet. When the payloadlength is zero, each message type handler reads uninitialized payloadand KMSAN detects this issue. The receipt of a packet with a zero-sizepayload is considered unexpected, and therefore, such packets should besilently discarded.This patch resolved this issue by checking payload size before callingeach message type handler codes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbmon: prevent division by zero in fb_videomode_from_videomode()The expression htotal * vtotal can have a zero value onoverflow. It is necessary to prevent division by zero like infb_var_to_videomode().Found by Linux Verification Center (linuxtesting.org) with Svace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Skip do PCI error slot reset during RAS recoveryWhy: The PCI error slot reset maybe triggered after inject ue to UMC multi times, this caused system hang. [ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume [ 557.373718] [drm] PCIE GART of 512M enabled. [ 557.373722] [drm] PTB located at 0x0000031FED700000 [ 557.373788] [drm] VRAM is lost due to GPU reset! [ 557.373789] [drm] PSP is resuming... [ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset [ 557.547067] [drm] PCI error: detected callback, state(1)!! [ 557.547069] [drm] No support for XGMI hive yet... [ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter [ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations [ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered [ 557.610492] [drm] PCI error: slot reset callback!! ... [ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI [ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu [ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023 [ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu] [ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00 [ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202 [ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0 [ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010 [ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08 [ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000 [ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000 [ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000 [ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0 [ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 560.843444] PKRU: 55555554 [ 560.846480] Call Trace: [ 560.849225] [ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea [ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea [ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.867778] ? show_regs.part.0+0x23/0x29 [ 560.872293] ? __die_body.cold+0x8/0xd [ 560.876502] ? die_addr+0x3e/0x60 [ 560.880238] ? exc_general_protection+0x1c5/0x410 [ 560.885532] ? asm_exc_general_protection+0x27/0x30 [ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.904520] process_one_work+0x228/0x3d0How: In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35936 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,as it could be caused only by two impossible conditions:- at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1- after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35951 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()Subject: [PATCH] drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()If some the pages or sgt allocation failed, we shouldn't release thepages ref we got earlier, otherwise we will end up with unbalancedget/put_pages() calls. We should instead leave everything in placeand let the BO release function deal with extra cleanup when the objectis destroyed, or let the fault handler try again next time it's called.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35952 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/ast: Fix soft lockupThere is a while-loop in ast_dp_set_on_off() that could lead toinfinite-loop. This is because the register, VGACRI-Dx, checked inthis API is a scratch register actually controlled by a MCU, namedDPMCU, in BMC.These scratch registers are protected by scu-lock. If suc-lock is notoff, DPMCU can not update these registers and then host will have softlockup due to never updated status.DPMCU is used to control DP and relative registers to handshake withhost's VGA driver. Even the most time-consuming task, DP's linktraining, is less than 100ms. 200ms should be enough.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35955 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kprobes: Fix possible use-after-free issue on kprobe registrationWhen unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will takea time. `is_module_text_address()` and `__module_text_address()`works with MODULE_STATE_LIVE and MODULE_STATE_GOING.If we use `is_module_text_address()` and `__module_text_address()`separately, there is a chance that the first one is succeeded but thenext one is failed because module->state becomes MODULE_STATE_UNFORMEDbetween those operations.In `check_kprobe_address_safe()`, if the second `__module_text_address()`is failed, that is ignored because it expected a kernel_text address.But it may have failed simply because module->state has been changedto MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modifynon-exist module text address (use-after-free).To fix this problem, we should not use separated `is_module_text_address()`and `__module_text_address()`, but use only `__module_text_address()`once and do `try_module_get(module)` which is only available withMODULE_STATE_LIVE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35965 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix not validating setsockopt user inputCheck user input length before copying data.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35966 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: RFCOMM: Fix not validating setsockopt user inputsyzbot reported rfcomm_sock_setsockopt_old() is copying data withoutchecking user input length.BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offsetinclude/linux/sockptr.h:49 [inline]BUG: KASAN: slab-out-of-bounds in copy_from_sockptrinclude/linux/sockptr.h:55 [inline]BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_oldnet/bluetooth/rfcomm/sock.c:632 [inline]BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70net/bluetooth/rfcomm/sock.c:673Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35967 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix not validating setsockopt user inputsyzbot reported sco_sock_setsockopt() is copying data withoutchecking user input length.BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offsetinclude/linux/sockptr.h:49 [inline]BUG: KASAN: slab-out-of-bounds in copy_from_sockptrinclude/linux/sockptr.h:55 [inline]BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90net/bluetooth/sco.c:893Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35973 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:geneve: fix header validation in geneve[6]_xmit_skbsyzbot is able to trigger an uninit-value in geneve_xmit() [1]Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())uses skb_protocol(skb, true), pskb_inet_may_pull() is only usingskb->protocol.If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol,pskb_inet_may_pull() does nothing at all.If a vlan tag was provided by the caller (af_packet in the syzbot case),the network header might not point to the correct location, and skblinear part could be smaller than expected.Add skb_vlan_inet_prepare() to perform a complete mac validation.Use this in geneve for the moment, I suspect we need to adopt thismore broadly.v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest - Only call __vlan_get_protocol() for vlan types.v2,v3 - Addressed Sabrina comments on v1 and v2[1]BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline] BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 geneve_xmit_skb drivers/net/geneve.c:910 [inline] geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35976 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RINGsyzbot reported an illegal copy in xsk_setsockopt() [1]Make sure to validate setsockopt() @optlen parameter.[1] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 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 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75RIP: 0033:0x7fb40587de69Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 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:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 Allocated by task 7549: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3966 [inline] __kmalloc+0x233/0x4a0 mm/slub.c:3979 kmalloc include/linux/slab.h:632 [inline] __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75The buggy address belongs to the object at ffff888028c6cde0 which belongs to the cache kmalloc-8 of size 8The buggy address is located 1 bytes to the right of allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)The buggy address belongs to the physical page:page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6canon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)page_type: 0xffffffff()raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as allocatedpage last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c:---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35978 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix memory leak in hci_req_sync_complete()In 'hci_req_sync_complete()', always free the previous syncrequest state before assigning reference to a new one.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35979 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:raid1: fix use-after-free for original bio in raid1_write_request()r1_bio->bios[] is used to record new bios that will be issued tounderlying disks, however, in raid1_write_request(), r1_bio->bios[]will set to the original bio temporarily. Meanwhile, if blocked rdevis set, free_r1bio() will be called causing that all r1_bio->bios[]to be freed:raid1_write_request() r1_bio = alloc_r1bio(mddev, bio); -> r1_bio->bios[] is NULL for (i = 0; i < disks; i++) -> for each rdev in conf // first rdev is normal r1_bio->bios[0] = bio; -> set to original bio // second rdev is blocked if (test_bit(Blocked, &rdev->flags)) break if (blocked_rdev) free_r1bio() put_all_bios() bio_put(r1_bio->bios[0]) -> original bio is freedTest scripts:mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-cleanfio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs=1 \ -iodepth=128 -name=test -direct=1echo blocked > /sys/block/md0/md/rd2/stateTest result:BUG bio-264 (Not tainted): Object already free-----------------------------------------------------------------------------Allocated in mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869 kmem_cache_alloc+0x324/0x480 mempool_alloc_slab+0x24/0x50 mempool_alloc+0x6e/0x220 bio_alloc_bioset+0x1af/0x4d0 blkdev_direct_IO+0x164/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0 io_submit_one+0x5ca/0xb70 __do_sys_io_submit+0x86/0x270 __x64_sys_io_submit+0x22/0x30 do_syscall_64+0xb1/0x210 entry_SYSCALL_64_after_hwframe+0x6c/0x74Freed in mempool_free_slab+0x1f/0x30 age=1 cpu=1 pid=869 kmem_cache_free+0x28c/0x550 mempool_free_slab+0x1f/0x30 mempool_free+0x40/0x100 bio_free+0x59/0x80 bio_put+0xf0/0x220 free_r1bio+0x74/0xb0 raid1_make_request+0xadf/0x1150 md_handle_request+0xc7/0x3b0 md_submit_bio+0x76/0x130 __submit_bio+0xd8/0x1d0 submit_bio_noacct_nocheck+0x1eb/0x5c0 submit_bio_noacct+0x169/0xd40 submit_bio+0xee/0x1d0 blkdev_direct_IO+0x322/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0Since that bios for underlying disks are not allocated yet, fix thisproblem by using mempool_free() directly to free the r1_bio.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: Avoid infinite loop trying to resize local TTIf the MTU of one of an attached interface becomes too small to transmitthe local translation table then it must be resized to fit inside allfragments (when enabled) or a single packet.But if the MTU becomes too low to transmit even the header + the VLANspecific part then the resizing of the local TT will never succeed. Thiscan for example happen when the usable space is 110 bytes and 11 VLANs areon top of batman-adv. In this case, at least 116 byte would be needed.There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)in the log but the function will never finish. Problem here is that thetimeout will be halved all the time and will then stagnate at 0 andtherefore never be able to reduce the table even more.There are other scenarios possible with a similar result. The number ofBATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be toohigh to fit inside a packet. Such a scenario can therefore happen also withonly a single VLAN + 7 non-purgable addresses - requiring at least 120bytes.While this should be handled proactively when:* interface with too low MTU is added* VLAN is added* non-purgeable local mac is added* MTU of an attached interface is reduced* fragmentation setting gets disabled (which most likely requires dropping attached interfaces)not all of these scenarios can be prevented because batman-adv is onlyconsuming events without the the possibility to prevent these actions(non-purgable MAC address added, MTU of an attached interface is reduced).It is therefore necessary to also make sure that the code is able to handlealso the situations when there were already incompatible systemconfiguration are present.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35984 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: smbus: fix NULL function pointer dereferenceBaruch reported an OOPS when using the designware controller as targetonly. Target-only modes break the assumption of one transfer functionalways being available. Fix this by always checking the pointer in__i2c_transfer.[wsa: dropped the simplification in core-smbus to avoid theoretical regressions]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35989 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Fix oops during rmmod on single-CPU platformsDuring the removal of the idxd driver, registered offline callback isinvoked as part of the clean up process. However, on systems with onlyone CPU online, no valid target is available to migrate theperf context, resulting in a kernel oops: BUG: unable to handle page fault for address: 000000000002a2b8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 1470e1067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57 Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023 RIP: 0010:mutex_lock+0x2e/0x50 ... Call Trace: __die+0x24/0x70 page_fault_oops+0x82/0x160 do_user_addr_fault+0x65/0x6b0 __pfx___rdmsr_safe_on_cpu+0x10/0x10 exc_page_fault+0x7d/0x170 asm_exc_page_fault+0x26/0x30 mutex_lock+0x2e/0x50 mutex_lock+0x1e/0x50 perf_pmu_migrate_context+0x87/0x1f0 perf_event_cpu_offline+0x76/0x90 [idxd] cpuhp_invoke_callback+0xa2/0x4f0 __pfx_perf_event_cpu_offline+0x10/0x10 [idxd] cpuhp_thread_fun+0x98/0x150 smpboot_thread_fn+0x27/0x260 smpboot_thread_fn+0x1af/0x260 __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x103/0x140 __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Fix the issue by preventing the migration of the perf context to aninvalid target.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-35990 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma: xilinx_dpdma: Fix lockingThere are several places where either chan->lock or chan->vchan.lock wasnot held. Add appropriate locking. This fixes lockdep warnings like[ 31.077578] ------------[ cut here ]------------[ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0[ 31.077953] Modules linked in:[ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98[ 31.078102] Hardware name: xlnx,zynqmp (DT)[ 31.078169] Workqueue: events_unbound deferred_probe_work_func[ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0[ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0[ 31.078550] sp : ffffffc083bb2e10[ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168[ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480[ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000[ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000[ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000[ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001[ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def[ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516[ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff[ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000[ 31.080307] Call trace:[ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0[ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120[ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac[ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c[ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684[ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0[ 31.081139] commit_tail+0x234/0x294[ 31.081246] drm_atomic_helper_commit+0x1f8/0x210[ 31.081363] drm_atomic_commit+0x100/0x140[ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384[ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c[ 31.081725] drm_client_modeset_commit+0x34/0x5c[ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168[ 31.081899] drm_fb_helper_set_par+0x50/0x70[ 31.081971] fbcon_init+0x538/0xc48[ 31.082047] visual_init+0x16c/0x23c[ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634[ 31.082320] do_take_over_console+0x24c/0x33c[ 31.082429] do_fbcon_takeover+0xbc/0x1b0[ 31.082503] fbcon_fb_registered+0x2d0/0x34c[ 31.082663] register_framebuffer+0x27c/0x38c[ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c[ 31.082939] drm_fb_helper_initial_config+0x50/0x74[ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108[ 31.083115] drm_client_register+0xa0/0xf4[ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc[ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0[ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0[ 31.083616] platform_probe+0x8c/0x13c[ 31.083713] really_probe+0x258/0x59c[ 31.083793] __driver_probe_device+0xc4/0x224[ 31.083878] driver_probe_device+0x70/0x1c0[ 31.083961] __device_attach_driver+0x108/0x1e0[ 31.084052] bus_for_each_drv+0x9c/0x100[ 31.084125] __device_attach+0x100/0x298[ 31.084207] device_initial_probe+0x14/0x20[ 31.084292] bus_probe_device+0xd8/0xdc[ 31.084368] deferred_probe_work_func+0x11c/0x180[ 31.084451] process_one_work+0x3ac/0x988[ 31.084643] worker_thread+0x398/0x694[ 31.084752] kthread+0x1bc/0x1c0[ 31.084848] ret_from_fork+0x10/0x20[ 31.084932] irq event stamp: 64549[ 31.084970] hardirqs last enabled at (64548): [] _raw_spin_unlock_irqrestore+0x80/0x90[ 31.085157]---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36004 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Do not use WQ_MEM_RECLAIM flag for workqueueIssue reported by customer during SRIOV testing, call trace:When both i40e and the i40iw driver are loaded, a warningin check_flush_dependency is being triggered. This seemsto be because of the i40e driver workqueue is allocated withthe WQ_MEM_RECLAIM flag, and the i40iw one is not.Similar error was encountered on ice too and it was fixed byremoving the flag. Do the same for i40e too.[Feb 9 09:08] ------------[ cut here ]------------[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] isflushing !WQ_MEM_RECLAIM infiniband:0x0[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966check_flush_dependency+0x10b/0x120[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seqsnd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtrrfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdmaintel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssifisst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermalintel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_coreiTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncoreioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ichintel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_padxfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbedrm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intellibata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirrordm_region_hash dm_log dm_mod fuse[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Nottainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1[ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOSSE5C620.86B.02.01.0013.121520200651 12/15/2020[ +0.000001] Workqueue: i40e i40e_service_task [i40e][ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120[ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 4881 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fdff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90[ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:0000000000000027[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:ffff94d47f620bc0[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:00000000ffff7fff[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:ffff94c5451ea180[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:ffff94c5f1330ab0[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)knlGS:0000000000000000[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:00000000007706f0[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400[ +0.000001] PKRU: 55555554[ +0.000001] Call Trace:[ +0.000001] [ +0.000002] ? __warn+0x80/0x130[ +0.000003] ? check_flush_dependency+0x10b/0x120[ +0.000002] ? report_bug+0x195/0x1a0[ +0.000005] ? handle_bug+0x3c/0x70[ +0.000003] ? exc_invalid_op+0x14/0x70[ +0.000002] ? asm_exc_invalid_op+0x16/0x20[ +0.000006] ? check_flush_dependency+0x10b/0x120[ +0.000002] ? check_flush_dependency+0x10b/0x120[ +0.000002] __flush_workqueue+0x126/0x3f0[ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core][ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core][ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core][ +0.000020] i40iw_close+0x4b/0x90 [irdma][ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e][ +0.000035] i40e_service_task+0x126/0x190 [i40e][ +0.000024] process_one_work+0x174/0x340[ +0.000003] worker_th---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36005 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: honor table dormant flag from netdev release event pathCheck for table dormant flag otherwise netdev release event path triesto unregister an already unregistered hook.[524854.857999] ------------[ cut here ]------------[524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260[...][524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365[524854.858869] Workqueue: netns cleanup_net[524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260[524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41[524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246[524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a[524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438[524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34[524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005[524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00[524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000[524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0[524854.859000] Call Trace:[524854.859006] [524854.859013] ? __warn+0x9f/0x1a0[524854.859027] ? __nf_unregister_net_hook+0x21a/0x260[524854.859044] ? report_bug+0x1b1/0x1e0[524854.859060] ? handle_bug+0x3c/0x70[524854.859071] ? exc_invalid_op+0x17/0x40[524854.859083] ? asm_exc_invalid_op+0x1a/0x20[524854.859100] ? __nf_unregister_net_hook+0x6a/0x260[524854.859116] ? __nf_unregister_net_hook+0x21a/0x260[524854.859135] nf_tables_netdev_event+0x337/0x390 [nf_tables][524854.859304] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables][524854.859461] ? packet_notifier+0xb3/0x360[524854.859476] ? _raw_spin_unlock_irqrestore+0x11/0x40[524854.859489] ? dcbnl_netdevice_event+0x35/0x140[524854.859507] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables][524854.859661] notifier_call_chain+0x7d/0x140[524854.859677] unregister_netdevice_many_notify+0x5e1/0xae0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()Extend a critical section to prevent chan from early freeing.Also make the l2cap_connect() return type void. Nothing is using thereturned value but it is ugly to return a potentially freed pointer.Making it void will help with backports because earlier kernels did usethe return value. Now the compile will break for kernels where thispatch is not a complete fix.Call stack summary:[use]l2cap_bredr_sig_cmd l2cap_connect mutex_lock(&conn->chan_lock); | chan = pchan->ops->new_connection(pchan); <- alloc chan | __l2cap_chan_add(conn, chan); | l2cap_chan_hold(chan); | list_add(&chan->list, &conn->chan_l); ... (1) mutex_unlock(&conn->chan_lock); chan->conf_state ... (4) <- use after free[free]l2cap_conn_del mutex_lock(&conn->chan_lock);| foreach chan in conn->chan_l: ... (2)| l2cap_chan_put(chan);| l2cap_chan_destroy| kfree(chan) ... (3) <- chan freed mutex_unlock(&conn->chan_lock);==================================================================BUG: KASAN: slab-use-after-free in instrument_atomic_readinclude/linux/instrumented.h:68 [inline]BUG: KASAN: slab-use-after-free in _test_bitinclude/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0net/bluetooth/l2cap_core.c:4260Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36014 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/arm/malidp: fix a possible null pointer dereferenceIn malidp_mw_connector_reset, new memory is allocated with kzalloc, butno check is performed. In order to prevent null pointer dereferencing,ensure that mw_state is checked before calling__drm_atomic_helper_connector_reset.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36270 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: tproxy: bail out if IP has been disabled on the devicesyzbot reports:general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f][..]RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62Call Trace: nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168__in_dev_get_rcu() can return NULL, so check for this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36476 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rtrs: Ensure 'ib_sge list' is accessibleMove the declaration of the 'ib_sge list' variable outside the'always_invalidate' block to ensure it remains accessible for usethroughout the function.Previously, 'ib_sge list' was declared within the 'always_invalidate'block, limiting its accessibility, then caused a'BUG: kernel NULL pointer dereference'[1]. ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2d0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? memcpy_orig+0xd5/0x140 rxe_mr_copy+0x1c3/0x200 [rdma_rxe] ? rxe_pool_get_index+0x4b/0x80 [rdma_rxe] copy_data+0xa5/0x230 [rdma_rxe] rxe_requester+0xd9b/0xf70 [rdma_rxe] ? finish_task_switch.isra.0+0x99/0x2e0 rxe_sender+0x13/0x40 [rdma_rxe] do_task+0x68/0x1e0 [rdma_rxe] process_one_work+0x177/0x330 worker_thread+0x252/0x390 ? __pfx_worker_thread+0x10/0x10This change ensures the variable is available for subsequent operationsthat require it.[1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36479 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fpga: bridge: add owner module and take its refcountThe current implementation of the fpga bridge assumes that the low-levelmodule registers a driver for the parent device and uses its owner pointerto take the module's refcount. This approach is problematic since it canlead to a null pointer dereference while attempting to get the bridge ifthe parent device does not have a driver.To address this problem, add a module owner pointer to the fpga_bridgestruct and use it to take the module's refcount. Modify the function forregistering a bridge to take an additional owner module parameter andrename it to avoid conflicts. Use the old function name for a helper macrothat automatically sets the module that registers the bridge as the owner.This ensures compatibility with existing low-level control modules andreduces the chances of registering a bridge without setting the owner.Also, update the documentation to keep it consistent with the new interfacefor registering an fpga bridge.Other changes: opportunistically move put_device() from __fpga_bridge_get()to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity sincethe bridge device is taken in these functions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36902 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()syzbot is able to trigger the following crash [1],caused by unsafe ip6_dst_idev() use.Indeed ip6_dst_idev() can return NULL, and must always be checked.[1]Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4cRSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bdR10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 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

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36908 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-iocost: do not WARN if iocg was already offlinedIn iocg_pay_debt(), warn is triggered if 'active_list' is empty, whichis intended to confirm iocg is active when it has debt. However, warncan be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0The warn in this situation is meaningless. Since this iocg is beingremoved, the state of the 'active_list' is irrelevant, and 'waitq_timer'is canceled after removing 'active_list' in ioc_pd_free(), which ensuresiocg is freed after iocg_waitq_timer_fn() returns.Therefore, add the check if iocg was already offlined to avoid warnwhen removing a blkcg or disk.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36909 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encryptedIn CoCo VMs it is possible for the untrusted host to causeset_memory_encrypted() or set_memory_decrypted() to fail such that anerror is returned and the resulting memory is shared. Callers need totake care to handle these errors to avoid returning decrypted (shared)memory to the page allocator, which could lead to functional or securityissues.The VMBus ring buffer code could free decrypted/shared pages ifset_memory_decrypted() fails. Check the decrypted field in the structvmbus_gpadl for the ring buffers to decide whether to free the memory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36912 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Track decrypted status in vmbus_gpadlIn CoCo VMs it is possible for the untrusted host to causeset_memory_encrypted() or set_memory_decrypted() to fail such that anerror is returned and the resulting memory is shared. Callers need totake care to handle these errors to avoid returning decrypted (shared)memory to the page allocator, which could lead to functional or securityissues.In order to make sure callers of vmbus_establish_gpadl() andvmbus_teardown_gpadl() don't return decrypted/shared pages toallocators, add a field in struct vmbus_gpadl to keep track of thedecryption status of the buffers. This will allow the callers toknow if they should free or leak the pages.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36914 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Skip on writeback when it's not applicable[WHY]dynamic memory safety error detector (KASAN) catches and generates errormessages "BUG: KASAN: slab-out-of-bounds" as writeback connector does notsupport certain features which are not initialized.[HOW]Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36917 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: fix overflow in blk_ioctl_discard()There is no check for overflow of 'start + len' in blk_ioctl_discard().Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000;Add the overflow validation now.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36941 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: don't free NULL coalescing ruleIf the parsing fails, we can dereference a NULL pointer here.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36944 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Reapply "drm/qxl: simplify qxl_fence_wait"This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.Stephen Rostedt reports: "I went to run my tests on my VMs and the tests hung on boot up. Unfortunately, the most I ever got out was: [ 93.607888] Testing event system initcall: OK [ 93.667730] Running tests on all trace events: [ 93.669757] Testing all events: OK [ 95.631064] ------------[ cut here ]------------ Timed out after 60 seconds"and further debugging points to a possible circular locking dependencybetween the console_owner locking and the worker pool locking.Reverting the commit allows Steve's VM to boot to completion again.[ This may obviously result in the "[TTM] Buffer eviction failed" messages again, which was the reason for that original revert. But at this point this seems preferable to a non-booting system... ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36946 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:phonet: fix rtm_phonet_notify() skb allocationfill_route() stores three components in the skb:- struct rtmsg- RTA_DST (u8)- RTA_OIF (u32)Therefore, rtm_phonet_notify() should useNLMSG_ALIGN(sizeof(struct rtmsg)) +nla_total_size(1) +nla_total_size(4)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36967 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KEYS: trusted: Fix memory leak in tpm2_key_encode()'scratch' is never freed. Fix this by calling kfree() in the success, andin the error case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36968 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()l2cap_le_flowctl_init() can cause both div-by-zero and an integeroverflow since hdev->le_mtu may not fall in the valid range.Move MTU from hci_dev to hci_conn to validate MTU and stop the connectionprocess earlier if MTU is invalid.Also, add a missing validation in read_buffer_size() and make it returnan error value if the validation fails.Now hci_conn_add() returns ERR_PTR() as it can fail due to the both akzalloc failure and invalid MTU value.divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: hci0 hci_rx_workRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8db7 88 00 00 00 4c 89 f0 48 c1 e8 03 42RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66fRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaaR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0PKRU: 55555554Call Trace: l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Modules linked in:---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-36969 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix division by zero in setup_dsc_configWhen slice_height is 0, the division by slice_height in the calculationof the number of slices will cause a division by zero driver crash. Thisleaves the kernel in a state that requires a reboot. This patch adds acheck to avoid the division by zero.The stack trace below is for the 6.8.4 Kernel. I reproduced the issue ona Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitorconnected via Thunderbolt. The amdgpu driver crashed with this exceptionwhen I rebooted the system with the monitor connected.kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpuAfter applying this patch, the driver no longer crashes when the monitoris connected and the system is rebooted. I believe this is the sameissue reported for 3113.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-37021 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fpga: manager: add owner module and take its refcountThe current implementation of the fpga manager assumes that the low-levelmodule registers a driver for the parent device and uses its owner pointerto take the module's refcount. This approach is problematic since it canlead to a null pointer dereference while attempting to get the manager ifthe parent device does not have a driver.To address this problem, add a module owner pointer to the fpga_managerstruct and use it to take the module's refcount. Modify the functions forregistering the manager to take an additional owner module parameter andrename them to avoid conflicts. Use the old function names for helpermacros that automatically set the module that registers the manager as theowner. This ensures compatibility with existing low-level control modulesand reduces the chances of registering a manager without setting the owner.Also, update the documentation to keep it consistent with the new interfacefor registering an fpga manager.Other changes: opportunistically move put_device() from __fpga_mgr_get() tofpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since themanager device is taken in these functions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38548 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm: bridge: cdns-mhdp8546: Fix possible null pointer dereferenceIn cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() isassigned to mhdp_state->current_mode, and there is a dereference of it indrm_mode_set_name(), which will lead to a NULL pointer dereference onfailure of drm_mode_duplicate().Fix this bug add a check of mhdp_state->current_mode.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38549 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Add 0 size check to mtk_drm_gem_objAdd a check to mtk_drm_gem_init if we attempt to allocate a GEM objectof 0 bytes. Currently, no such check exists and the kernel will panic ifa userspace application attempts to allocate a 0x0 GBM buffer.Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 andverifying that we now return EINVAL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38556 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Add a timeout to acquire the command queue semaphorePrevent forced completion handling on an entry that has not yet beenassigned an index, causing an out of bounds access on idx = -22.Instead of waiting indefinitely for the sem, blocking flow now waits forindex to be allocated or a sem acquisition timeout before beginning thetimer for FW completion.Kernel log example:mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38573 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cppc_cpufreq: Fix possible null pointer dereferencecppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called fromdifferent places with various parameters. So cpufreq_cpu_get() can returnnull as 'policy' in some circumstances.Fix this bug by adding null return check.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38586 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:r8169: Fix possible ring buffer corruption on fragmented Tx packets.An issue was found on the RTL8125b when transmitting small fragmentedpackets, whereby invalid entries were inserted into the transmit ringbuffer, subsequently leading to calls to dma_unmap_single() with a nulladdress.This was caused by rtl8169_start_xmit() not noticing changes to nr_fragswhich may occur when small packets are padded (to work around hardwarequirks) in rtl8169_tso_csum_v2().To fix this, postpone inspecting nr_frags until after any padding has beenapplied.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38588 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix possible use-after-free issue in ftrace_location()KASAN reports a bug: BUG: KASAN: use-after-free in ftrace_location+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcf/0x610 kasan_report+0xb5/0xe0 ftrace_location+0x90/0x120 register_kprobe+0x14b/0xa40 kprobe_init+0x2d/0xff0 [kprobe_example] do_one_initcall+0x8f/0x2d0 do_init_module+0x13a/0x3c0 load_module+0x3082/0x33d0 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0x306/0x440 do_syscall_64+0x68/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79The root cause is that, in lookup_rec(), ftrace record of some addressis being searched in ftrace pages of some module, but those ftrace pagesat the same time is being freed in ftrace_release_mod() as thecorresponding module is being deleted: CPU1 | CPU2 register_kprobes() { | delete_module() { check_kprobe_address_safe() { | arch_check_ftrace_location() { | ftrace_location() { | lookup_rec() // USE! | ftrace_release_mod() // Free!To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range(); 2. Use ftrace_location_range() instead of lookup_rec() in ftrace_location(); 3. Call synchronize_rcu() before freeing any ftrace pages both in ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38619 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb-storage: alauda: Check whether the media is initializedThe member "uzonesize" of struct alauda_info will remain 0if alauda_init_media() fails, potentially causing divide errorsin alauda_read_data() and alauda_write_lba().- Add a member "media_initialized" to struct alauda_info.- Change a condition in alauda_check_media() to ensure the first initialization.- Add an error check for the return value of alauda_init_media().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38621 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: stk1160: fix bounds checking in stk1160_copy_video()The subtract in this condition is reversed. The ->length is the lengthof the buffer. The ->bytesused is how many bytes we have copied thusfar. When the condition is reversed that means the result of thesubtraction is always negative but since it's unsigned then the resultis a very high positive value. That means the overflow check is nevertrue.Additionally, the ->bytesused doesn't actually work for this purposebecause we're not writing to "buf->mem + buf->bytesused". Instead, themath to calculate the destination where we are writing is a bitinvolved. You calculate the number of full lines already written,multiply by two, skip a line if necessary so that we start on an oddnumbered line, and add the offset into the line.To fix this buffer overflow, just take the actual destination where weare writing, if the offset is already out of bounds print an error andreturn. Otherwise, write up to buf->length bytes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38627 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:stm class: Fix a double free in stm_register_device()The put_device(&stm->dev) call will trigger stm_device_release() whichfrees "stm" so the vfree(stm) on the next line is a double free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38633 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: max3100: Update uart_driver_registered on driver removalThe removal of the last MAX3100 device triggers the removal ofthe driver. However, code doesn't update the respective globalvariable and after insmod - rmmod - insmod cycle the kerneloopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0Update the actual state so next time UART driver will be registeredagain.Hugo also noticed, that the error path in the probe also affectedby having the variable set, and not cleared. Instead of clearing itmove the assignment after the successfull uart_register_driver() call.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38634 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: max3100: Lock port->lock when calling uart_handle_cts_change()uart_handle_cts_change() has to be called with port lock taken,Since we run it in a separate work, the lock may not be taken atthe time of running. Make sure that it's taken by explicitly doingthat. Without it we got a splat: WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 [max3100]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38635 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soundwire: cadence: fix invalid PDI offsetFor some reason, we add an offset to the PDI, presumably to skip thePDI0 and PDI1 which are reserved for BPT.This code is however completely wrong and leads to an out-of-boundsaccess. We were just lucky so far since we used only a couple of PDIsand remained within the PDI array bounds.A Fixes: tag is not provided since there are no known platforms wherethe out-of-bounds would be accessed, and the initial code had problemsas well.A follow-up patch completely removes this useless offset.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38661 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/ap: Fix crash in AP internal function modify_bitmap()A system crash like this Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403 Fault in home space mode while using kernel ASCE. AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d Oops: 0038 ilc:3 [#1] PREEMPT SMP Modules linked in: mlx5_ib ... CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8 Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8) 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:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 lhi %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Call Trace: [<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8 ([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8) [<0000014b75e7b758>] apmask_store+0x68/0x140 [<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8 [<0000014b75598524>] vfs_write+0x1b4/0x448 [<0000014b7559894c>] ksys_write+0x74/0x100 [<0000014b7618a440>] __do_syscall+0x268/0x328 [<0000014b761a3558>] system_call+0x70/0x98 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8 Kernel panic - not syncing: Fatal exception: panic_on_oopsoccured when /sys/bus/ap/a[pq]mask was updated with a relative mask value(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.The fix is simple: use unsigned long values for the internal variables. Thecorrect checks are already in place in the function but a simple int forthe internal variables was used with the possibility to overflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-38780 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf/sw-sync: don't enable IRQ from sync_print_obj()Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore fromknown context") by error replaced spin_unlock_irqrestore() withspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despitesync_print_obj() is called from sync_debugfs_show(), lockdep complainsinconsistent lock state warning.Use plain spin_{lock,unlock}() for sync_print_obj(), forsync_debugfs_show() is already using spin_{lock,unlock}_irq().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-39488 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRYWhen CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytesto bug_table entries, and as a result the last entry in a bug table willbe ignored, potentially leading to an unexpected panic(). All priorentries in the table will be handled correctly.The arm64 ABI requires that struct fields of up to 8 bytes arenaturally-aligned, with padding added within a struct such that structare suitably aligned within arrays.When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes }... with 12 bytes total, requiring 4-byte alignment.When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes }... with 8 bytes total, with 6 bytes of data and 2 bytes of trailingpadding, requiring 4-byte alginment.When we create a bug_entry in assembly, we align the start of the entryto 4 bytes, which implicitly handles padding for any prior entries.However, we do not align the end of the entry, and so whenCONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing paddingbytes.For the main kernel image this is not a problem as find_bug() doesn'tdepend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug;However for modules, module_bug_finalize() depends on the trailingbytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);... and as the last bug_entry lacks the necessary padding bytes, this entrywill not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out;... which can lead to a kenrel panic due to an unhandled bug.This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL");... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-39499 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vmci: prevent speculation leaks by sanitizing event in event_deliver()Coverity spotted that event_msg is controlled by user-space,event_msg->event_data.event is passed to event_deliver() and usedas an index without sanitization.This change ensures that the event index is sanitized to mitigate anypossibility of speculative information leaks.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.Only compile tested, no access to HW.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-39506 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packetIn lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value,but then it is unconditionally passed to skb_add_rx_frag() which looksstrange and could lead to null pointer dereference.lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)In this path there is no code which sets pg_info->page to NULL.So this check looks unneeded and doesn't solve potential problem.But I guess the author had reason to add a check and I have no such cardand can't do real test.In addition, the code in the function liquidio_push_packet() inliquidio/lio_core.c does exactly the same.Based on this, I consider the most acceptable compromise solution toadjust this issue by moving skb_add_rx_frag() into conditional scope.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-39509 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: remove unnecessary WARN_ON() in implement()Syzkaller hit a warning [1] in a call to implement() when tryingto write a value into a field of smaller size in an output report.Since implement() already has a warn message printed out with thehelp of hid_warn() and value in question gets trimmed with: ... value &= m; ...WARN_ON may be considered superfluous. Remove it to suppress futuresyzkaller triggers.[1]WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863Modules linked in:CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863...Call Trace: __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline] usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 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...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40904 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messagesThe syzbot fuzzer found that the interrupt-URB completion callback inthe cdc-wdm driver was taking too long, and the driver's immediateresubmission of interrupt URBs with -EPROTO status combined with thedummy-hcd emulation to cause a CPU lockup:cdc_wdm 1-1:1.0: nonzero urb status received: -71cdc_wdm 1-1:1.0: wdm_int_callback - 0 byteswatchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]CPU#0 Utilization every 4s during lockup: #1: 98% system, 0% softirq, 3% hardirq, 0% idle #2: 98% system, 0% softirq, 3% hardirq, 0% idle #3: 98% system, 0% softirq, 3% hardirq, 0% idle #4: 98% system, 0% softirq, 3% hardirq, 0% idle #5: 98% system, 1% softirq, 3% hardirq, 0% idleModules linked in:irq event stamp: 73096hardirqs last enabled at (73095): [] console_emit_next_record kernel/printk/printk.c:2935 [inline]hardirqs last enabled at (73095): [] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994hardirqs last disabled at (73096): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]hardirqs last disabled at (73096): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551softirqs last enabled at (73048): [] softirq_handle_end kernel/softirq.c:400 [inline]softirqs last enabled at (73048): [] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582softirqs last disabled at (73043): [] __do_softirq+0x14/0x20 kernel/softirq.c:588CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Testing showed that the problem did not occur if the two errormessages -- the first two lines above -- were removed; apparently addingmaterial to the kernel log takes a surprisingly large amount of time.In any case, the best approach for preventing these lockups and toavoid spamming the log with thousands of error messages per second isto ratelimit the two dev_err() calls. Therefore we replace them withdev_err_ratelimited().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40905 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix possible race in __fib6_drop_pcpu_from()syzbot found a race in __fib6_drop_pcpu_from() [1]If compiler reads more than once (*ppcpu_rt),second read could read NULL, if another cpu clearsthe value in rt6_get_pcpu_route().Add a READ_ONCE() to prevent this race.Also add rcu_read_lock()/rcu_read_unlock() becausewe rely on RCU protection while dereferencing pcpu_rt.[1]Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Workqueue: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48RSP: 0018:ffffc900040df070 EFLAGS: 00010206RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline] fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038 fib6_del_route net/ipv6/ip6_fib.c:1998 [inline] fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043 fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205 fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127 fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175 fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255 __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271 rt6_sync_down_dev net/ipv6/route.c:4906 [inline] rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911 addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifier_call_chain+0xb9/0x410 kernel/notifier.c:93 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992 call_netdevice_notifiers_extack net/core/dev.c:2030 [inline] call_netdevice_notifiers net/core/dev.c:2044 [inline] dev_close_many+0x333/0x6a0 net/core/dev.c:1585 unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193 unregister_netdevice_many net/core/dev.c:11276 [inline] default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40911 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: Lock wiphy in cfg80211_get_stationWiphy should be locked before calling rdev_get_station() (see lockdepassert in ieee80211_get_station()).This fixes the following kernel NULL dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x0000000096000006 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 = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000 [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: netconsole dwc3_meson_g12a dwc3_of_simple dwc3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705 Hardware name: RPT (r1) (DT) Workqueue: bat_events batadv_v_elp_throughput_metric_update pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath10k_sta_statistics+0x10/0x2dc [ath10k_core] lr : sta_set_sinfo+0xcc/0xbd4 sp : ffff000007b43ad0 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98 x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000 x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000 x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000 x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000 x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90 x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000 Call trace: ath10k_sta_statistics+0x10/0x2dc [ath10k_core] sta_set_sinfo+0xcc/0xbd4 ieee80211_get_station+0x2c/0x44 cfg80211_get_station+0x80/0x154 batadv_v_elp_get_throughput+0x138/0x1fc batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x1ec/0x414 worker_thread+0x70/0x46c kthread+0xdc/0xe0 ret_from_fork+0x10/0x20 Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814)This happens because STA has time to disconnect and reconnect beforebatadv_v_elp_throughput_metric_update() delayed work gets scheduled. Inthis situation, ath10k_sta_state() can be in the middle of resettingarsta data when the work queue get chance to be scheduled and ends upaccessing it. Locking wiphy prevents that.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40912 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock tosynchronizes with ieee80211_tx_h_unicast_ps_buf() which is called fromsoftirq context. However using only spin_lock() to get sta->ps_lock inieee80211_sta_ps_deliver_wakeup() does not prevent softirq to executeon this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try totake this same lock ending in deadlock. Below is an example of rcu stallthat arises in such situation. rcu: INFO: rcu_sched self-detected stall on CPU rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996 rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4) CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742 Hardware name: RPT (r1) (DT) pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : queued_spin_lock_slowpath+0x58/0x2d0 lr : invoke_tx_handlers_early+0x5b4/0x5c0 sp : ffff00001ef64660 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8 Call trace: queued_spin_lock_slowpath+0x58/0x2d0 ieee80211_tx+0x80/0x12c ieee80211_tx_pending+0x110/0x278 tasklet_action_common.constprop.0+0x10c/0x144 tasklet_action+0x20/0x28 _stext+0x11c/0x284 ____do_softirq+0xc/0x14 call_on_irq_stack+0x24/0x34 do_softirq_own_stack+0x18/0x20 do_softirq+0x74/0x7c __local_bh_enable_ip+0xa0/0xa4 _ieee80211_wake_txqs+0x3b0/0x4b8 __ieee80211_wake_queue+0x12c/0x168 ieee80211_add_pending_skbs+0xec/0x138 ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480 ieee80211_mps_sta_status_update.part.0+0xd8/0x11c ieee80211_mps_sta_status_update+0x18/0x24 sta_apply_parameters+0x3bc/0x4c0 ieee80211_change_station+0x1b8/0x2dc nl80211_set_station+0x444/0x49c genl_family_rcv_msg_doit.isra.0+0xa4/0xfc genl_rcv_msg+0x1b0/0x244 netlink_rcv_skb+0x38/0x10c genl_rcv+0x34/0x48 netlink_unicast+0x254/0x2bc netlink_sendmsg+0x190/0x3b4 ____sys_sendmsg+0x1e8/0x218 ___sys_sendmsg+0x68/0x8c __sys_sendmsg+0x44/0x84 __arm64_sys_sendmsg+0x20/0x28 do_el0_svc+0x6c/0xe8 el0_svc+0x14/0x48 el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x14c/0x150Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raiseon the same CPU that is holding the lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40929 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: check n_ssids before accessing the ssidsIn some versions of cfg80211, the ssids poinet might be a valid one eventhough n_ssids is 0. Accessing the pointer in this case will cuase anout-of-bound access. Fix this by checking n_ssids first.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40941 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: don't read past the mfuart notifcationIn case the firmware sends a notification that claims it has more datathan it has, we will read past that was allocated for the notification.Remove the print of the buffer, we won't see it by default. If needed,we can see the content with tracing.This was reported by KFENCE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40942 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: mesh: Fix leak of mesh_preq_queue objectsThe hwmp code use objects of type mesh_preq_queue, added to a list inieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpathgets deleted, ex mesh interface is removed, the entries in that list willnever get cleaned. Fix this by flushing all corresponding items of thepreq_queue in mesh_path_flush_pending().This should take care of KASAN reports like this:unreferenced object 0xffff00000668d800 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>........... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20unreferenced object 0xffff000009051f00 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s) hex dump (first 32 bytes): 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h..... 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.......Xy..... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40953 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure theloads and stores are atomic. In the extremely unlikely scenario thecompiler tears the stores, it's theoretically possible for KVM to attemptto get a vCPU using an out-of-bounds index, e.g. if the write is splitinto multiple 8-bit stores, and is paired with a 32-bit load on a VM with257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff];As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x00000012 -> 0x00000000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40958 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netns: Make get_net_ns() handle zero refcount netSyzkaller hit a warning:refcount_t: addition on 0; use-after-free.WARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0Modules linked in:CPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:refcount_warn_saturate+0xdf/0x1d0Code: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 <0f> 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1RSP: 0018:ffff8881067b7da0 EFLAGS: 00010286RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72acRDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139R10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040FS: 00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? show_regs+0xa3/0xc0 ? __warn+0xa5/0x1c0 ? refcount_warn_saturate+0xdf/0x1d0 ? report_bug+0x1fc/0x2d0 ? refcount_warn_saturate+0xdf/0x1d0 ? handle_bug+0xa1/0x110 ? exc_invalid_op+0x3c/0xb0 ? asm_exc_invalid_op+0x1f/0x30 ? __warn_printk+0xcc/0x140 ? __warn_printk+0xd5/0x140 ? refcount_warn_saturate+0xdf/0x1d0 get_net_ns+0xa4/0xc0 ? __pfx_get_net_ns+0x10/0x10 open_related_ns+0x5a/0x130 __tun_chr_ioctl+0x1616/0x2370 ? __sanitizer_cov_trace_switch+0x58/0xa0 ? __sanitizer_cov_trace_const_cmp2+0x1c/0x30 ? __pfx_tun_chr_ioctl+0x10/0x10 tun_chr_ioctl+0x2f/0x40 __x64_sys_ioctl+0x11b/0x160 x64_sys_call+0x1211/0x20d0 do_syscall_64+0x9e/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f5b28f165d7Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7RDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0R10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000 Kernel panic - not syncing: kernel: panic_on_warn set ...This is trigger as below: ns0 ns1tun_set_iff() //dev is tun0 tun->dev = dev//ip link set tun0 netns ns1 put_net() //ref is 0__tun_chr_ioctl() //TUNGETDEVNETNS net = dev_net(tun->dev); open_related_ns(&net->ns, get_net_ns); //ns1 get_net_ns() get_net() //addition on 0Use maybe_get_net() in get_net_ns in case net's ref is zero to fix this

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40959 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.syzbot reported:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00RSP: 0018:ffffc90000117378 EFLAGS: 00010246RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline] xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline] xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541 xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835 xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline] xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201 xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline] xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309 ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256 send6+0x611/0xd20 drivers/net/wireguard/socket.c:139 wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178 wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200 wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40 wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40970 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Avoid hw_desc array overrun in dw-axi-dmacI have a use case where nr_buffers = 3 and in which each descriptor is composed by 3segments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put()handles the hw_desc considering the descs_allocated, this scenario would result in akernel panic (hw_desc array will be overrun).To fix this, the proposal is to add a new member to the axi_dma_desc structure,where we keep the number of allocated hw_descs (axi_desc_alloc()) and use it inaxi_desc_put() to handle the hw_desc array correctly.Additionally I propose to remove the axi_chan_start_first_queued() call after completingthe transfer, since it was identified that unbalance can occur (started descriptors canbe interrupted and transfer ignored due to DMA channel not being enabled).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40982 Severity: Moderate CVSS3 score: 5.5

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

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40983 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: force a dst refcount before doing decryptionAs it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount beforeentering the xfrm type handlers"):"Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers."On TIPC decryption path it has the same problem, and skb_dst_force()should be called before doing decryption to avoid a possible crash.Shuang reported this issue when this warning is triggered: [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug [] Workqueue: crypto cryptd_queue_worker [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc] [] tipc_rcv+0xcf5/0x1060 [tipc] [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc] [] cryptd_aead_crypt+0xdb/0x190 [] cryptd_queue_worker+0xed/0x190 [] process_one_work+0x93d/0x17e0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40984 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid"Info: mapping multiple BARs. Your kernel is fine.""). The initialpurpose of this commit was to stop memory mappings for operationregions from overlapping page boundaries, as it can trigger warningsif different page attributes are present.However, it was found that when this situation arises, mappingcontinues until the boundary's end, but there is still an attempt toread/write the entire length of the map, leading to a NULL pointerdeference. For example, if a four-byte mapping request is made butonly one byte is mapped because it hits the current page boundary'send, a four-byte read/write attempt is still made, resulting in a NULLpointer deference.Instead, map the entire length, as the ACPI specification does notmandate that it must be within the same page boundary. It ispermissible for it to be mapped across different regions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40988 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: fix UBSAN warning in kv_dpm.cAdds bounds check for sumo_vid_mapping_entry.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40995 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()syzbot found hanging tasks waiting on rtnl_lock [1]A reproducer is available in the syzbot bug.When a request to add multiple actions with the same index is sent, thesecond request will block forever on the first request. This holdsrtnl_lock, and causes tasks to hang.Return -EAGAIN to prevent infinite looping, while keeping documentedbehavior.[1]INFO: task kworker/1:0:5088 blocked for more than 143 seconds.Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000Workqueue: events_power_efficient reg_check_chans_workCall Trace:context_switch kernel/sched/core.c:5409 [inline]__schedule+0xf15/0x5d00 kernel/sched/core.c:6746__schedule_loop kernel/sched/core.c:6823 [inline]schedule+0xe7/0x350 kernel/sched/core.c:6838schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895__mutex_lock_common kernel/locking/mutex.c:684 [inline]__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752wiphy_lock include/net/cfg80211.h:5953 [inline]reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-40998 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super()In the following concurrency we will access the uninitialized rs->lock:ext4_fill_super ext4_register_sysfs // sysfs registered msg_ratelimit_interval_ms // Other processes modify rs->interval to // non-zero via msg_ratelimit_interval_ms ext4_orphan_cleanup ext4_msg(sb, KERN_INFO, "Errors on filesystem, " __ext4_msg ___ratelimit(&(EXT4_SB(sb)->s_msg_ratelimit_state) if (!rs->interval) // do nothing if interval is 0 return 1; raw_spin_trylock_irqsave(&rs->lock, flags) raw_spin_trylock(lock) _raw_spin_trylock __raw_spin_trylock spin_acquire(&lock->dep_map, 0, 1, _RET_IP_) lock_acquire __lock_acquire register_lock_class assign_lock_key dump_stack(); ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10); raw_spin_lock_init(&rs->lock); // init rs->lock hereand get the following dump_stack:=========================================================INFO: trying to register non-static key.The code is fine but needs lockdep annotation, or maybeyou didn't initialize this object before use?turning off the locking correctness validator.CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504[...]Call Trace: dump_stack_lvl+0xc5/0x170 dump_stack+0x18/0x30 register_lock_class+0x740/0x7c0 __lock_acquire+0x69/0x13a0 lock_acquire+0x120/0x450 _raw_spin_trylock+0x98/0xd0 ___ratelimit+0xf6/0x220 __ext4_msg+0x7f/0x160 [ext4] ext4_orphan_cleanup+0x665/0x740 [ext4] __ext4_fill_super+0x21ea/0x2b10 [ext4] ext4_fill_super+0x14d/0x360 [ext4][...]=========================================================Normally interval is 0 until s_msg_ratelimit_state is initialized, so___ratelimit() does nothing. But registering sysfs precedes initializingrs->lock, so it is possible to change rs->interval to a non-zero valuevia the msg_ratelimit_interval_ms interface of sysfs while rs->lock isuninitialized, and then a call to ext4_msg triggers the problem byaccessing an uninitialized rs->lock. Therefore register sysfs after allinitializations are complete to avoid such problems.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41016 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()xattr in ocfs2 maybe 'non-indexed', which saved with additional spacerequested. It's better to check if the memory is out of bound beforememcmp, although this possibility mainly comes from crafted poisonousimages.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41017 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: don't walk off the end of ealistAdd a check before visiting the members of ea tomake sure each ea stays within the ealist.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41027 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Fix userfaultfd_api to return EINVAL as expectedCurrently if we request a feature that is not set in the Kernel config wefail silently and return all the available features. However, the manpage indicates we should return an EINVAL.We need to fix this issue since we can end up with a Kernel warning shoulda program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel withthe config not set with this feature. [ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660 [ 200.820738] Modules linked in: [ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8 [ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022 [ 200.885052] RIP: 0010:zap_pte_range+0x43d/0x660

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41035 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptorSyzbot has identified a bug in usbcore (see the Closes: tag below)caused by our assumption that the reserved bits in an endpointdescriptor's bEndpointAddress field will always be 0. As a result ofthe bug, the endpoint_is_duplicate() routine in config.c (and possiblyother routines as well) may believe that two descriptors are fordistinct endpoints, even though they have the same direction andendpoint number. This can lead to confusion, including the bugidentified by syzbot (two descriptors with matching endpoint numbersand directions, where one was interrupt and the other was bulk).To fix the bug, we will clear the reserved bits in bEndpointAddresswhen we parse the descriptor. (Note that both the USB-2.0 and USB-3.1specs say these bits are "Reserved, reset to zero".) This requires usto make a copy of the descriptor earlier in usb_parse_endpoint() anduse the copy instead of the original when checking for duplicates.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41056 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw filesUse strnlen() instead of strlen() on the algorithm and coefficient namestring arrays in V1 wmfw files.In V1 wmfw files the name is a NUL-terminated string in a fixed-sizearray. cs_dsp should protect against overrunning the array if the NULterminator is missing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41079 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet: always initialize cqe.resultThe spec doesn't mandate that the first two double words (aka results)for the command queue entry need to be set to 0 when they are notused (not specified). Though, the target implemention returns 0 for TCPand FC but not for RDMA.Let's make RDMA behave the same and thus explicitly initializing theresult field. This prevents leaking any data from the stack.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41080 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix possible deadlock in io_register_iowq_max_workers()The io_register_iowq_max_workers() function calls io_put_sq_data(),which acquires the sqd->lock without releasing the uring_lock.Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx->uring_lockbefore acquiring sqd->lock"), this can lead to a potential deadlocksituation.To resolve this issue, the uring_lock is released before callingio_put_sq_data(), and then it is re-acquired after the function call.This change ensures that the locks are acquired in the correctorder, preventing the possibility of a deadlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41081 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ila: block BH in ila_output()As explained in commit 1378817486d6 ("tipc: block BHbefore using dst_cache"), net/core/dst_cache.chelpers need to be called with BH disabled.ila_output() is called from lwtunnel_output()possibly from process context, and under rcu_read_lock().We might be interrupted by a softirq, re-enter ila_output()and corrupt dst_cache data structures.Fix the race by using local_bh_disable().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41088 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: mcp251xfd: fix infinite loop when xmit failsWhen the mcp251xfd_start_xmit() function fails, the driver stopsprocessing messages, and the interrupt routine does not return,running indefinitely even after killing the running application.Error messages:[ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16[ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).... and repeat forever.The issue can be triggered when multiple devices share the same SPIinterface. And there is concurrent access to the bus.The problem occurs because tx_ring->head increments even ifmcp251xfd_start_xmit() fails. Consequently, the driver skips one TXpackage while still expecting a response inmcp251xfd_handle_tefif_one().Resolve the issue by starting a workqueue to write the tx objsynchronously if err = -EBUSY. In case of another error, decrementtx_ring->head, remove skb from the echo stack, and drop the message.[mkl: use more imperative wording in patch description]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41097 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: atm: cxacru: fix endpoint checking in cxacru_bind()Syzbot is still reporting quite an old issue [1] that occurs due toincomplete checking of present usb endpoints. As such, wrongendpoints types may be used at urb sumbitting stage which in turntriggers a warning in usb_submit_urb().Fix the issue by verifying that required endpoint types are presentfor both in and out endpoints, taking into account cmd endpoint type.Unfortunately, this patch has not been tested on real hardware.[1] Syzbot report:usb 1-1: BOGUS urb xfer, pipe 1 != type 3WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502Modules linked in:CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502...Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-41149 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: avoid to reuse `hctx` not removed from cpuhp callback listIf the 'hctx' isn't removed from cpuhp callback list, we can't reuse it,otherwise use-after-free may be triggered.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: Fix possible double free in error handling pathWhen auxiliary_device_add() returns error and then callsauxiliary_device_uninit(), callback function adev_releasecalls kfree(madev). We shouldn't call kfree(madev) againin the error handling path. Set 'madev' to NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42076 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: can: j1939: Initialize unused data in j1939_send_one()syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()creates full frame including unused data, but it doesn't initializeit. This causes the kernel-infoleak issue. Fix this by initializingunused data.[1]BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] memcpy_to_msg include/linux/skbuff.h:4113 [inline] raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 ____sys_recvmsg+0x18a/0x620 net/socket.c:2803 ___sys_recvmsg+0x223/0x840 net/socket.c:2845 do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034 x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1313 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 sock_alloc_send_skb include/net/sock.h:1842 [inline] j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline] j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline] j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fBytes 12-15 of 16 are uninitializedMemory access of size 16 starts at ffff888120969690Data copied to user address 00000000200017c0CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42080 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/restrack: Fix potential invalid address accessstruct rdma_restrack_entry's kern_name was set to KBUILD_MODNAMEin ib_create_cq(), while if the module exited but forgot del thisrdma_restrack_entry, it would cause a invalid address access inrdma_restrack_clean() when print the owner of this rdma_restrack_entry.These code is used to help find one forgotten PD release in one of theULPs. But it is not needed anymore, so delete them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42082 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xdp: Remove WARN() from __xdp_reg_mem_model()syzkaller reports a warning in __xdp_reg_mem_model().The warning occurs only if __mem_id_init_hash_table() returns an error. Itreturns the error in two cases: 1. memory allocation fails; 2. rhashtable_init() fails when some fields of rhashtable_params struct are not initialized properly.The second case cannot happen since there is a static const rhashtable_paramsstruct with valid fields. So, warning is only triggered when there is aproblem with memory allocation.Thus, there is no sense in using WARN() to handle this error and it can besafely removed.WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299Call Trace: xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344 xdp_test_run_setup net/bpf/test_run.c:188 [inline] bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649 __do_sys_bpf kernel/bpf/syscall.c:5738 [inline] __se_sys_bpf kernel/bpf/syscall.c:5736 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75Found by Linux Verification Center (linuxtesting.org) with syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42089 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: fsl-asoc-card: set priv->pdev before using itpriv->pdev pointer was set after being used infsl_asoc_card_audmux_init().Move this assignment at the start of the probe function, sosub-functions can correctly use pdev through priv.fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to thedev struct, used with dev_err macros.As priv is zero-initialised, there would be a NULL pointer dereference.Note that if priv->dev is dereferenced before assignment but never used,for example if there is no error to be printed, the driver won't crashprobably due to compiler optimisations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFERIn create_pinctrl(), pinctrl_maps_mutex is acquired before callingadd_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()calls pinctrl_free(). However, pinctrl_free() attempts to acquirepinctrl_maps_mutex, which is already held by create_pinctrl(), leading toa potential deadlock.This patch resolves the issue by releasing pinctrl_maps_mutex beforecalling pinctrl_free(), preventing the deadlock.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42095 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250_omap: Implementation of Errata i2310As per Errata i2310[0], Erroneous timeout can be triggered,if this Erroneous interrupt is not cleared then it may leadsto storm of interrupts, therefore apply Errata i2310 solution.[0] https://www.ti.com/lit/pdf/sprz536 page 23

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42101 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: fix null pointer dereference in nouveau_connector_get_modesIn nouveau_connector_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a possible NULL pointerdereference on failure of drm_mode_duplicate(). Add a check to avoid npd.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42106 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:inet_diag: Initialize pad field in struct inet_diag_req_v2KMSAN reported uninit-value access in raw_lookup() [1]. Diag for rawsockets uses the pad field in struct inet_diag_req_v2 for theunderlying protocol. This field corresponds to the sdiag_raw_protocolfield in struct inet_diag_req_raw.inet_diag_get_exact_compat() converts inet_diag_req toinet_diag_req_v2, but leaves the pad field uninitialized. So the issueoccurs when raw_lookup() accesses the sdiag_raw_protocol field.Fix this by initializing the pad field ininet_diag_get_exact_compat(). Also, do the same fix ininet_diag_dump_compat() to avoid the similar issue in the future.[1]BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4/raw_diag.c:49 [inline] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was stored to memory at: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fLocal variable req.i created at: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42107 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Don't process extts if PTP is disabledThe ice_ptp_extts_event() function can race with ice_ptp_release() andresult in a NULL pointer dereference which leads to a kernel panic.Panic occurs because the ice_ptp_extts_event() function callsptp_clock_event() with a NULL pointer. The ice driver has alreadyreleased the PTP clock by the time the interrupt for the next externaltimestamp event occurs.To fix this, modify the ice_ptp_extts_event() function to check thePTP state and bail early if PTP is not ready.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42110 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx()The following is emitted when using idxd (DSA) dmanegine as the datamover for ntb_transport that ntb_netdev uses.[74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526[74412.556784] caller is netif_rx_internal+0x42/0x130[74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5[74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024[74412.581699] Call Trace:[74412.584514] [74412.586933] dump_stack_lvl+0x55/0x70[74412.591129] check_preemption_disabled+0xc8/0xf0[74412.596374] netif_rx_internal+0x42/0x130[74412.600957] __netif_rx+0x20/0xd0[74412.604743] ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev][74412.610985] ntb_complete_rxc+0xed/0x140 [ntb_transport][74412.617010] ntb_rx_copy_callback+0x53/0x80 [ntb_transport][74412.623332] idxd_dma_complete_txd+0xe3/0x160 [idxd][74412.628963] idxd_wq_thread+0x1a6/0x2b0 [idxd][74412.634046] irq_thread_fn+0x21/0x60[74412.638134] ? irq_thread+0xa8/0x290[74412.642218] irq_thread+0x1a0/0x290[74412.646212] ? __pfx_irq_thread_fn+0x10/0x10[74412.651071] ? __pfx_irq_thread_dtor+0x10/0x10[74412.656117] ? __pfx_irq_thread+0x10/0x10[74412.660686] kthread+0x100/0x130[74412.664384] ? __pfx_kthread+0x10/0x10[74412.668639] ret_from_fork+0x31/0x50[74412.672716] ? __pfx_kthread+0x10/0x10[74412.676978] ret_from_fork_asm+0x1a/0x30[74412.681457] The cause is due to the idxd driver interrupt completion handler usesthreaded interrupt and the threaded handler is not hard or soft interruptcontext. However __netif_rx() can only be called from interrupt context.Change the call to netif_rx() in order to allow completion via normalcontext for dmaengine drivers that utilize threaded irq handling.While the following commit changed from netif_rx() to __netif_rx(),baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context."),the change should've been a noop instead. However, the code precedes thisfix should've been using netif_rx_ni() or netif_rx_any_context().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42114 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM valuessyzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUMto 2^31.We had a similar issue in sch_fq, fixed with commitd9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]Modules linked in:irq event stamp: 131135 hardirqs last enabled at (131134): [] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs last disabled at (131135): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (131135): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (125892): [] neigh_hh_init net/core/neighbour.c:1538 [inline] softirqs last enabled at (125892): [] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553 softirqs last disabled at (125896): [] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Workqueue: mld mld_ifc_workpstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del include/linux/list.h:195 [inline] pc : __list_del_entry include/linux/list.h:218 [inline] pc : list_move_tail include/linux/list.h:310 [inline] pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline] pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr : __list_del_entry include/linux/list.h:218 [inline] lr : list_move_tail include/linux/list.h:310 [inline] lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline] lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854sp : ffff800093d36700x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffffx11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fcx2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470Call trace: __list_del include/linux/list.h:195 [inline] __list_del_entry include/linux/list.h:218 [inline] list_move_tail include/linux/list.h:310 [inline] fq_tin_dequeue include/net/fq_impl.h:112 [inline] ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 wake_tx_push_queue net/mac80211/util.c:294 [inline] ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline] schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline] ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664 ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062 __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338 ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547 __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563 neigh_output include/net/neighbour.h:542 [inline] ip6_fini---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42120 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check pipe offset before setting vblankpipe_ctx has a size of MAX_PIPES so checking its index before accessingthe array.This fixes an OVERRUN issue reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42121 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check index msg_id before read or write[WHAT]msg_id is used as an array index and it cannot be a negative value, andtherefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1).[HOW]Check whether msg_id is valid before reading and setting.This fixes 4 OVERRUN issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42122 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 kzalloc[Why & How]Check return pointer of kzalloc before using it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42124 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Make qedf_execute_tmf() non-preemptibleStop calling smp_processor_id() from preemptible code inqedf_execute_tmf90. This results in BUG_ON() when running an RT kernel.[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646[ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42130 Severity: Moderate CVSS3 score: 5.5

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

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42139 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix improper extts handlingExtts events are disabled and enabled by the application ts2phc.However, in case where the driver is removed when the application isrunning, a specific extts event remains enabled and can cause a kernelcrash.As a side effect, when the driver is reloaded and application is startedagain, remaining extts event for the channel from a previous run willkeep firing and the message "extts on unexpected channel" might beprinted to the user.To avoid that, extts events shall be disabled when PTP is released.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42148 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bnx2x: Fix multiple UBSAN array-index-out-of-boundsFix UBSAN warnings that occur when using a system with 32 physicalcpu cores or more, or when the user defines a number of Ethernetqueues greater than or equal to FP_SB_MAX_E1x using the num_queuesmodule parameter.Currently there is a read/write out of bounds that occurs on the array"struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".Looking at the definition of the "struct stats_query_entry query" array:struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX];FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts andhas a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3meaning the array has a total size of 19.Since accesses to "struct stats_query_entry query" are offset-ted byBNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernetqueues should not exceed FP_SB_MAX_E1x (16). However one of these queuesis reserved for FCOE and thus the number of Ethernet queues should be setto [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) ifit is not.This is also described in a comment in the source code indrivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definitionof FP_SB_MAX_E1x. Below is the part of this explanation that it importantfor this patch/* * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of * regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues * is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for * slow-path interrupts) or Y+2 if CNIC is supported (one additional * FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE * L2 queue is supported. The cid for the FCoE L2 queue is always X. */However this driver also supports NICs that use the E2 controller which canhandle more queues due to having more FP-SB represented by FP_SB_MAX_E2.Looking at the commits when the E2 support was added, it was originallyusing the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driverwas later updated to take full advantage of the E2 instead of having it belimited to the capabilities of the E1x. But as far as we can tell, thearray "stats_query_entry query" was still limited to using the FP-SBavailable to the E1x cards as part of an oversignt when the driver wasupdated to take full advantage of the E2, and now with the driver beingaware of the greater queue size supported by E2 NICs, it causes the UBSANwarnings seen in the stack traces below.This patch increases the size of the "stats_query_entry query" array byreplacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handleboth types of NICs.Stack traces:UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11index 20 is out of range for type 'stats_query_entry [19]'CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42154 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: validate source addr lengthI don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn't have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42156 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Wipe copies of clear-key structures on failureWipe all sensitive data from stack for all IOCTLs, which convert aclear-key into a protected- or secure-key.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42157 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Wipe sensitive data on failureWipe sensitive data from stack also if the copy_to_user() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42158 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Use kfree_sensitive() to fix Coccinelle warningsReplace memzero_explicit() and kfree() with kfree_sensitive() to fixwarnings reported by Coccinelle:WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42162 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: Account for stopped queues when reading NIC statsWe now account for the fact that the NIC might send us stats for asubset of queues. Without this change, gve_get_ethtool_stats might makean invalid access on the priv->stats_report->stats array.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42224 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: Correct check for empty listSince commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIObusses") mv88e6xxx_default_mdio_bus() has checked that thereturn value of list_first_entry() is non-NULL.This appears to be intended to guard against the list chip->mdios beingempty. However, it is not the correct check as the implementation oflist_first_entry is not designed to return NULL for empty lists.Instead, use list_first_entry_or_null() which does return NULL if thelist is empty.Flagged by Smatch.Compile tested only.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42228 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_relocInitialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: cs_dsp: Validate payload length before processing blockMove the payload length check in cs_dsp_load() and cs_dsp_coeff_load()to be done before the block is processed.The check that the length of a block payload does not exceed the numberof remaining bytes in the firwmware file buffer was being done near theend of the loop iteration. However, some code before that check used thelength field without validating it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42238 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: cs_dsp: Return error if block header overflows fileReturn an error from cs_dsp_power_up() if a block header is longerthan the amount of data left in the file.The previous code in cs_dsp_load() and cs_dsp_load_coeff() would loopwhile there was enough data left in the file for a valid region. Thisprotected against overrunning the end of the file data, but it didn'tabort the file processing with an error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42244 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: serial: mos7840: fix crash on resumeSince commit c49cfa917025 ("USB: serial: use generic method if noalternative is provided in usb serial layer"), USB serial core calls thegeneric resume implementation when the driver has not provided one.This can trigger a crash on resume with mos7840 since support formultiple read URBs was added back in 2011. Specifically, both port readURBs are now submitted on resume for open ports, but the context pointerof the second URB is left set to the core rather than mos7840 portstructure.Fix this by implementing dedicated suspend and resume functions formos7840.Tested with Delock 87414 USB 2.0 to 4x serial adapter.[ johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42246 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socketWhen using a BPF program on kernel_connect(), the call can return -EPERM. Thiscauses xs_tcp_setup_socket() to loop forever, filling up the syslog and causingthe kernel to potentially freeze up.Neil suggested: This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.ECONNREFUSED as error seems reasonable. For programs setting a different errorcan be out of reach (see handling in 4fbac77d2d09) in particular on kernelswhich do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -errinstead of allow boolean"), thus given that it is better to simply remap forconsistent behavior. UDP does handle EPERM in xs_udp_send_request().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42247 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wireguard: allowedips: avoid unaligned 64-bit memory accessesOn the parisc platform, the kernel issues kernel warnings becauseswap_endian() tries to load a 128-bit IPv6 address from an unalignedmemory location: Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)Avoid such unaligned memory accesses by instead using theget_unaligned_be64() helper macro.[Jason: replace src[8] in original patch with src+8]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42280 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: Fix a use after free in hfcmulti_tx()Don't dereference *sp after calling dev_kfree_skb(*sp).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42281 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix a segment issue when downgrading gso_sizeLinearize the skb when downgrading gso_size because it may trigger aBUG_ON() later when the skb is segmented as described in [1,2].

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42283 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: nexthop: Initialize all fields in dumped nexthopsstruct nexthop_grp contains two reserved fields that are not initialized bynla_put_nh_group(), and carry garbage. This can be observed e.g. withstrace (edited for clarity): # ip nexthop add id 1 dev lo # ip nexthop add id 101 group 1 # strace -e recvmsg ip nexthop get id 101 ... recvmsg(... [{nla_len=12, nla_type=NHA_GROUP}, [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52The fields are reserved and therefore not currently used. But as they are, theyleak kernel memory, and the fact they are not just zero complicates repurposingof the fields for new ends. Initialize the full structure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42284 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Return non-zero value from tipc_udp_addr2str() on errortipc_udp_addr2str() should return non-zero value if the UDP mediaaddress is invalid. Otherwise, a buffer overflow access can occur intipc_media_addr_printf(). Fix this by returning 1 on an invalid UDPmedia address.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42285 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix a use-after-free related to destroying CM IDsiw_conn_req_handler() associates a new struct rdma_id_private (conn_id) withan existing struct iw_cm_id (cm_id) as follows: conn_id->cm_id.iw = cm_id; cm_id->context = conn_id; cm_id->cm_handler = cma_iw_handler;rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Makesure that cm_work_handler() does not trigger a use-after-free by onlyfreeing of the struct rdma_id_private after all pending work has finished.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42290 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/imx-irqsteer: Handle runtime power management correctlyThe power domain is automatically activated from clk_prepare(). However, oncertain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokessleeping functions, which triggers the 'scheduling while atomic' bug in thecontext switch path during device probing: BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0x20 mutex_lock+0x48/0x54 clk_prepare_lock+0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chipcallbacks and handle power management in them as they are invoked fromnon-atomic context.[ tglx: Rewrote change log, added Fixes tag ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42291 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Add a per-VF limit on number of FDIR filtersWhile the iavf driver adds a s/w limit (128) on the number of FDIRfilters that the VF can request, a malicious VF driver can request morethan that and exhaust the resources for other VFs.Add a similar limit in ice.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42295 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: handle inconsistent state in nilfs_btnode_create_block()Syzbot reported that a buffer state inconsistency was detected innilfs_btnode_create_block(), triggering a kernel bug.It is not appropriate to treat this inconsistency as a bug; it can occurif the argument block address (the buffer index of the newly createdblock) is a virtual block number and has been reallocated due tocorruption of the bitmap used to manage its allocation state.So, modify nilfs_btnode_create_block() and its callers to treat it as apossible filesystem error, rather than triggering a kernel bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42304 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: make sure the first directory block is not a holeThe syzbot constructs a directory that has no dirblock but is non-inline,i.e. the first directory block is a hole. And no errors are reported whencreating files in this directory in the following flow. ext4_mknod ... ext4_add_entry // Read block 0 ext4_read_dirblock(dir, block, DIRENT) bh = ext4_bread(NULL, inode, block, 0) if (!bh && (type == INDEX || type == DIRENT_HTREE)) // The first directory block is a hole // But type == DIRENT, so no error is reported.After that, we get a directory block without '.' and '..' but with a validdentry. This may cause some code that relies on dot or dotdot (such asmake_indexed_dir()) to crash.Therefore when ext4_read_dirblock() finds that the first directory blockis a hole report that the filesystem is corrupted and return an error toavoid loading corrupted data from disk causing something bad.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42305 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: check dot and dotdot of dx_root before making dir indexedSyzbot reports a issue as follows:============================================BUG: unable to handle page fault for address: ffffed11022e24fePGD 23ffee067 P4D 23ffee067 PUD 0Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTICPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0Call Trace: make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214[...]============================================The immediate cause of this problem is that there is only one valid dentryfor the block to be split during do_split, so split==0 results in out ofbounds accesses to the map triggering the issue. do_split unsigned split dx_make_map count = 1 split = count/2 = 0; continued = hash2 == map[split - 1].hash; ---> map[4294967295]The maximum length of a filename is 255 and the minimum block size is 1024,so it is always guaranteed that the number of entries is greater than orequal to 2 when do_split() is called.But syzbot's crafted image has no dot and dotdot in dir, and the dentrydistribution in dirblock is as follows: bus dentry1 hole dentry2 free|xx--|xx-------------|...............|xx-------------|...............|0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024So when renaming dentry1 increases its name_len length by 1, neither holenor free is sufficient to hold the new dentry, and make_indexed_dir() iscalled.In make_indexed_dir() it is assumed that the first two entries of thedirblock must be dot and dotdot, so bus and dentry1 are left in dx_rootbecause they are treated as dot and dotdot, and only dentry2 is movedto the new leaf block. That's why count is equal to 1.Therefore add the ext4_check_dx_root() helper function to add more sanitychecks to dot and dotdot before starting the conversion to avoid the aboveissue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42306 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udf: Avoid using corrupted block bitmap bufferWhen the filesystem block bitmap is corrupted, we detect the corruptionwhile loading the bitmap and fail the allocation with error. However thenext allocation from the same bitmap will notice the bitmap buffer isalready loaded and tries to allocate from the bitmap with mixed results(depending on the exact nature of the bitmap corruption). Fix theproblem by using BH_verified bit to indicate whether the bitmap is validor not.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42309 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modesIn psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() isassigned to mode, which will lead to a possible NULL pointer dereferenceon failure of drm_mode_duplicate(). Add a check to avoid npd.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42310 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modesIn cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a NULL pointer dereference onfailure of drm_mode_duplicate(). Add a check to avoid npd.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42312 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sysctl: always initialize i_uid/i_gidAlways initialize i_uid/i_gid inside the sysfs core so set_ownership()can safely skip setting them.Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values ofi_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid whenset_ownership() was not implemented. It also missed adjustingnet_ctl_set_ownership() to use the same default values in case thecomputation of a better value failed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42318 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:landlock: Don't lose track of restrictions on cred_transferWhen a process' cred struct is replaced, this _almost_ always invokesthe cred_prepare LSM hook; but in one special case (whenKEYCTL_SESSION_TO_PARENT updates the parent's credentials), thecred_transfer LSM hook is used instead. Landlock only implements thecred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causesall information on Landlock restrictions to be lost.This basically means that a process with the ability to use the fork()and keyctl() syscalls can get rid of all Landlock restrictions onitself.Fix it by adding a cred_transfer hook that does the same thing as theexisting cred_prepare hook. (Implemented by having hook_cred_prepare()call hook_cred_transfer() so that the two functions are less likely toaccidentally diverge in the future.)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42321 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: flow_dissector: use DEBUG_NET_WARN_ON_ONCEThe following splat is easy to reproduce upstream as well as in -stablekernels. Florian Westphal provided the following commit: d1dab4f71d37 ("net: add and use __skb_get_hash_symmetric_net")but this complementary fix has been also suggested by Willem de Bruijnand it can be easily backported to -stable kernel which consists inusing DEBUG_NET_WARN_ON_ONCE instead to silence the following splatgiven __skb_get_hash() is used by the nftables tracing infrastructure toto identify packets in traces.[69133.561393] ------------[ cut here ]------------[69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/[...][69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379[69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0[69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ffff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8[69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246[69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19[69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418[69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000[69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400[69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28[69133.562020] FS: 00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000[69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0[69133.562040] Call Trace:[69133.562044] [69133.562049] ? __warn+0x9f/0x1a0[ 1211.841384] ? __skb_flow_dissect+0x107e/0x2860[...][ 1211.841496] ? bpf_flow_dissect+0x160/0x160[ 1211.841753] __skb_get_hash+0x97/0x280[ 1211.841765] ? __skb_get_hash_symmetric+0x230/0x230[ 1211.841776] ? mod_find+0xbf/0xe0[ 1211.841786] ? get_stack_info_noinstr+0x12/0xe0[ 1211.841798] ? bpf_ksym_find+0x56/0xe0[ 1211.841807] ? __rcu_read_unlock+0x2a/0x70[ 1211.841819] nft_trace_init+0x1b9/0x1c0 [nf_tables][ 1211.841895] ? nft_trace_notify+0x830/0x830 [nf_tables][ 1211.841964] ? get_stack_info+0x2b/0x80[ 1211.841975] ? nft_do_chain_arp+0x80/0x80 [nf_tables][ 1211.842044] nft_do_chain+0x79c/0x850 [nf_tables]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-42322 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: properly dereference pe in ip_vs_add_serviceUse pe directly to resolve sparse warning: net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43817 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: missing check virtioTwo missing check in virtio_net_hdr_to_skb() allowed syzbotto crash kernels again1. After the skb_segment function the buffer may become non-linear(nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywherethe __skb_linearize function will not be executed, then the buffer willremain non-linear. Then the condition (offset >= skb_headlen(skb))becomes true, which causes WARN_ON_ONCE in skb_checksum_help.2. The struct sk_buff and struct virtio_net_hdr members must bemathematically related.(gso_size) must be greater than (needed) otherwise WARN_ON_ONCE.(remainder) must be greater than (needed) otherwise WARN_ON_ONCE.(remainder) may be 0 if division is without remainder.offset+2 (4191) > skb_headlen() (1116)WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303Modules linked in:CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 <0f> 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 efRSP: 0018:ffffc90003a9f338 EFLAGS: 00010286RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045cR13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105dFS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777 ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584 ip_finish_output_gso net/ipv4/ip_output.c:286 [inline] __ip_finish_output net/ipv4/ip_output.c:308 [inline] __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:451 [inline] ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129 iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline] sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3545 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6bFound by Linux Verification Center (linuxtesting.org) with Syzkaller

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43819 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kvm: s390: Reject memory region operations for ucontrol VMsThis change rejects the KVM_SET_USER_MEMORY_REGION andKVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM.This is necessary since ucontrol VMs have kvm->arch.gmap set to 0 andwould thus result in a null pointer dereference further in.Memory management needs to be performed in userspace and using theioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGIONand KVM_SET_USER_MEMORY_REGION2.[frankja@linux.ibm.com: commit message spelling fix, subject prefix fix]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43821 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix a possible null pointer dereferenceIn function lpfc_xcvr_data_show, the memory allocation with kmalloc mightfail, thereby making rdp_context a null pointer. In the following contextand functions that use this pointer, there are dereferencing operations,leading to null pointer dereference.To fix this issue, a null pointer check should be added. If it is null,use scnprintf to notify the user and return len.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43824 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init()Instead of getting the epc_features from pci_epc_get_features() API, usethe cached pci_epf_test::epc_features value to avoid the NULL check. Sincethe NULL check is already performed in pci_epf_test_bind(), having one morecheck in pci_epf_test_core_init() is redundant and it is not possible tohit the NULL pointer dereference.Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier"flag"), 'epc_features' got dereferenced without the NULL check, leading tothe following false positive Smatch warning: drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747)Thus, remove the redundant NULL check and also use the epc_features::{msix_capable/msi_capable} flags directly to avoid local variables.[kwilczynski: commit log]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43828 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix infinite loop when replaying fast_commitWhen doing fast_commit replay an infinite loop may occur due to anuninitialized extent_status struct. ext4_ext_determine_insert_hole() doesnot detect the replay and calls ext4_es_find_extent_range(), which willreturn immediately without initializing the 'es' variable.Because 'es' contains garbage, an integer overflow may happen causing aninfinite loop in this function, easily reproducible using fstest generic/039.This commit fixes this issue by unconditionally initializing the structurein function ext4_es_find_extent_range().Thanks to Zhang Yi, for figuring out the real problem!

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43831 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: Handle invalid decoder vsiHandle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsiis valid for future use.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43832 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/uv: Don't call folio_wait_writeback() without a folio referencefolio_wait_writeback() requires that no spinlocks are held and thata folio reference is held, as documented. After we dropped the PTL, thefolio could get freed concurrently. So grab a temporary reference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43834 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xdp: fix invalid wait context of page_pool_destroy()If the driver uses a page pool, it creates a page pool withpage_pool_create().The reference count of page pool is 1 as default.A page pool will be destroyed only when a reference count reaches 0.page_pool_destroy() is used to destroy page pool, it decreases areference count.When a page pool is destroyed, ->disconnect() is called, which ismem_allocator_disconnect().This function internally acquires mutex_lock().If the driver uses XDP, it registers a memory model withxdp_rxq_info_reg_mem_model().The xdp_rxq_info_reg_mem_model() internally increases a page poolreference count if a memory model is a page pool.Now the reference count is 2.To destroy a page pool, the driver should call both page_pool_destroy()and xdp_unreg_mem_model().The xdp_unreg_mem_model() internally calls page_pool_destroy().Only page_pool_destroy() decreases a reference count.If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), wewill face an invalid wait context warning.Because xdp_unreg_mem_model() calls page_pool_destroy() withrcu_read_lock().The page_pool_destroy() internally acquires mutex_lock().Splat looks like:=============================[ BUG: Invalid wait context ]6.10.0-rc6+ #4 Tainted: G W-----------------------------ethtool/1806 is trying to lock:ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150other info that might help us debug this:context-{5:5}3 locks held by ethtool/1806:stack backtrace:CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fedHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021Call Trace:dump_stack_lvl+0x7e/0xc0__lock_acquire+0x1681/0x4de0? _printk+0x64/0xe0? __pfx_mark_lock.part.0+0x10/0x10? __pfx___lock_acquire+0x10/0x10lock_acquire+0x1b3/0x580? mem_allocator_disconnect+0x73/0x150? __wake_up_klogd.part.0+0x16/0xc0? __pfx_lock_acquire+0x10/0x10? dump_stack_lvl+0x91/0xc0__mutex_lock+0x15c/0x1690? mem_allocator_disconnect+0x73/0x150? __pfx_prb_read_valid+0x10/0x10? mem_allocator_disconnect+0x73/0x150? __pfx_llist_add_batch+0x10/0x10? console_unlock+0x193/0x1b0? lockdep_hardirqs_on+0xbe/0x140? __pfx___mutex_lock+0x10/0x10? tick_nohz_tick_stopped+0x16/0x90? __irq_work_queue_local+0x1e5/0x330? irq_work_queue+0x39/0x50? __wake_up_klogd.part.0+0x79/0xc0? mem_allocator_disconnect+0x73/0x150mem_allocator_disconnect+0x73/0x150? __pfx_mem_allocator_disconnect+0x10/0x10? mark_held_locks+0xa5/0xf0? rcu_is_watching+0x11/0xb0page_pool_release+0x36e/0x6d0page_pool_destroy+0xd7/0x440xdp_unreg_mem_model+0x1a7/0x2a0? __pfx_xdp_unreg_mem_model+0x10/0x10? kfree+0x125/0x370? bnxt_free_ring.isra.0+0x2eb/0x500? bnxt_free_mem+0x5ac/0x2500xdp_rxq_info_unreg+0x4a/0xd0bnxt_free_mem+0x1356/0x2500bnxt_close_nic+0xf0/0x3b0? __pfx_bnxt_close_nic+0x10/0x10? ethnl_parse_bit+0x2c6/0x6d0? __pfx___nla_validate_parse+0x10/0x10? __pfx_ethnl_parse_bit+0x10/0x10bnxt_set_features+0x2a8/0x3e0__netdev_update_features+0x4dc/0x1370? ethnl_parse_bitset+0x4ff/0x750? __pfx_ethnl_parse_bitset+0x10/0x10? __pfx___netdev_update_features+0x10/0x10? mark_held_locks+0xa5/0xf0? _raw_spin_unlock_irqrestore+0x42/0x70? __pm_runtime_resume+0x7d/0x110ethnl_set_features+0x32d/0xa20To fix this problem, it uses rhashtable_lookup_fast() instead ofrhashtable_lookup() with rcu_read_lock().Using xa without rcu_read_lock() here is safe.xa is freed by __xdp_mem_allocator_rcu_free() and this is called bycall_rcu() of mem_xa_remove().The mem_xa_remove() is called by page_pool_destroy() if a referencecount reaches 0.The xa is already protected by the reference count mechanism well in thecontrol plane.So removing rcu_read_lock() for page_pool_destroy() is safe.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43835 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virtio_net: Fix napi_skb_cache_put warningAfter the commit bdacf3e34945 ("net: Use nested-BH locking fornapi_alloc_cache.") was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 handle_bug+0x3d/0x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10The issue arises because virtio is assuming it's running in NAPI contexteven when it's not, such as in the netpoll case.To resolve this, modify virtnet_poll_tx() to only set NAPI when budgetis available. Same for virtnet_poll_cleantx(), which always assumed thatit was in a NAPI context.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43837 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXTWhen loading a EXT program without specifying `attr->attach_prog_fd`,the `prog->aux->dst_prog` will be null. At this time, callingresolve_prog_type() anywhere will result in a null pointer dereference.Example stack trace:[ 8.107863] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004[ 8.108262] Mem abort info:[ 8.108384] ESR = 0x0000000096000004[ 8.108547] EC = 0x25: DABT (current EL), IL = 32 bits[ 8.108722] SET = 0, FnV = 0[ 8.108827] EA = 0, S1PTW = 0[ 8.108939] FSC = 0x04: level 0 translation fault[ 8.109102] Data abort info:[ 8.109203] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 8.109399] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 8.109614] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 8.109836] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101354000[ 8.110011] [0000000000000004] pgd=0000000000000000, p4d=0000000000000000[ 8.112624] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 8.112783] Modules linked in:[ 8.113120] CPU: 0 PID: 99 Comm: may_access_dire Not tainted 6.10.0-rc3-next-20240613-dirty #1[ 8.113230] Hardware name: linux,dummy-virt (DT)[ 8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 8.113429] pc : may_access_direct_pkt_data+0x24/0xa0[ 8.113746] lr : add_subprog_and_kfunc+0x634/0x8e8[ 8.113798] sp : ffff80008283b9f0[ 8.113813] x29: ffff80008283b9f0 x28: ffff800082795048 x27: 0000000000000001[ 8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000[ 8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000[ 8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff[ 8.113929] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720[ 8.113944] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720[ 8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9 : ffff80008021f4e4[ 8.113991] x8 : 0101010101010101 x7 : 746f72705f6d656d x6 : 000000001e0e0f5f[ 8.114006] x5 : 000000000001864f x4 : ffff0000c12b8000 x3 : 000000000000001c[ 8.114020] x2 : 0000000000000002 x1 : 0000000000000000 x0 : 0000000000000000[ 8.114126] Call trace:[ 8.114159] may_access_direct_pkt_data+0x24/0xa0[ 8.114202] bpf_check+0x3bc/0x28c0[ 8.114214] bpf_prog_load+0x658/0xa58[ 8.114227] __sys_bpf+0xc50/0x2250[ 8.114240] __arm64_sys_bpf+0x28/0x40[ 8.114254] invoke_syscall.constprop.0+0x54/0xf0[ 8.114273] do_el0_svc+0x4c/0xd8[ 8.114289] el0_svc+0x3c/0x140[ 8.114305] el0t_64_sync_handler+0x134/0x150[ 8.114331] el0t_64_sync+0x168/0x170[ 8.114477] Code: 7100707f 54000081 f9401c00 f9403800 (b9400403)[ 8.118672] ---[ end trace 0000000000000000 ]---One way to fix it is by forcing `attach_prog_fd` non-empty whenbpf_prog_load(). But this will lead to `libbpf_probe_bpf_prog_type`API broken which use verifier log to probe prog type and will lognothing if we reject invalid EXT prog before bpf_check().Another way is by adding null check in resolve_prog_type().The issue was introduced by commit 4a9c7bbe2ed4 ("bpf: Resolve toprog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT") which wantedto correct type resolution for BPF_PROG_TYPE_TRACING programs. Beforethat, the type resolution of BPF_PROG_TYPE_EXT prog actually followsthe logic below: prog->aux->dst_prog ? prog->aux->dst_prog->type : prog->type;It implies that when EXT program is not yet attached to `dst_prog`,the prog type should be EXT itself. This code worked fine in the past.So just keep using it.Fix this by returning `prog->type` for BPF_PROG_TYPE_EXT if `dst_prog`is not present in resolve_prog_type().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43839 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bna: adjust 'name' buf size of bna_tcb and bna_ccb structuresTo have enough space to write all possible sprintf() args. Currently'name' size is 16, but the first '%s' specifier may already need atleast 16 characters, since 'bnad->netdev->name' is used there.For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16And replace sprintf with snprintf.Detected using the static analysis tool - Svace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43841 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: virt_wifi: avoid reporting connection success with wrong SSIDWhen user issues a connection with a different SSID than the onevirt_wifi has advertised, the __cfg80211_connect_result() willtrigger the warning: WARN_ON(bss_not_found).The issue is because the connection code in virt_wifi does notcheck the SSID from user space (it only checks the BSSID), andvirt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESSeven if the SSID is different from the one virt_wifi has advertised.Eventually cfg80211 won't be able to find the cfg80211_bss and generatethe warning.Fixed it by checking the SSID (from user space) in the connection code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43856 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma: fix call order in dmam_free_coherentdmam_free_coherent() frees a DMA allocation, which makes thefreed vaddr available for reuse, then calls devres_destroy()to remove and free the data structure used to track the DMAallocation. Between the two calls, it is possible for aconcurrent task to make an allocation with the same vaddrand add it to the devres list.If this happens, there will be two entries in the devres listwith the same vaddr and devres_destroy() can free the wrongentry, triggering the WARN_ON() in dmam_match.Fix by destroying the devres entry before freeing the DMAallocation. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43858 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: Fix array-index-out-of-bounds in diFree

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43860 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: imx_rproc: Skip over memory region when node value is NULLIn imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just countsnumber of phandles. But phandles may be empty. So of_parse_phandle() inthe parsing loop (0 < a < nph) may return NULL which is later dereferenced.Adjust this issue by adding NULL-return check.Found by Linux Verification Center (linuxtesting.org) with SVACE.[Fixed title to fit within the prescribed 70-75 charcters]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix a deadlock in dma buf fence pollingIntroduce a version of the fence ops that on release doesn't removethe fence from the pending list, and thus doesn't require a lock tofix poll->fence wait->fence unref deadlocks.vmwgfx overwrites the wait callback to iterate over the list of allfences and update their status, to do that it holds a lock to preventthe list modifcations from other threads. The fence destroy callbackboth deletes the fence and removes it from the list of pendingfences, for which it holds a lock.dma buf polling cb unrefs a fence after it's been signaled: so the pollcalls the wait, which signals the fences, which are being destroyed.The destruction tries to acquire the lock on the pending fences listwhich it can never get because it's held by the wait from which itwas called.Old bug, but not a lot of userspace apps were using dma-buf pollinginterfaces. Fix those, in particular this fixes KDE stalls/deadlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43866 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Always drain health in shutdown callbackThere is no point in recovery during device shutdown. if healthwork started need to wait for it to avoid races and NULL pointeraccess.Hence, drain health WQ on shutdown callback.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43867 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: prime: fix refcount underflowCalling nouveau_bo_ref() on a nouveau_bo without initializing it (andhence the backing ttm_bo) leads to a refcount underflow.Instead of calling nouveau_bo_ref() in the unwind path ofdrm_gem_object_init(), clean things up manually.(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43871 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:devres: Fix memory leakage caused by driver API devm_free_percpu()It will cause memory leakage when use driver API devm_free_percpu()to free memory allocated by devm_alloc_percpu(), fixed by usingdevres_release() instead of devres_destroy() within devm_free_percpu().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43872 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix soft lockup under heavy CEQE loadCEQEs are handled in interrupt handler currently. This may cause theCPU core staying in interrupt context too long and lead to soft lockupunder heavy load.Handle CEQEs in BH workqueue and set an upper limit for the number ofCEQE handled by a single call of work handler.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43873 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vhost/vsock: always initialize seqpacket_allowThere are two issues around seqpacket_allow:1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized.2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this).To fix: - initialize seqpacket_allow after allocation - set it unconditionally in set_features

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43879 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled incfg80211_calculate_bitrate_he(), leading to below warning:kernel: invalid HE MCS: bw:6, ru:6kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43880 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_erp: Fix object nesting warningACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM(A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former cancontain more ACLs (i.e., tc filters), but the number of masks in eachregion (i.e., tc chain) is limited.In order to mitigate the effects of the above limitation, the deviceallows filters to share a single mask if their masks only differ in upto 8 consecutive bits. For example, dst_ip/25 can be represented usingdst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on thenumber of masks being used (and therefore does not support maskaggregation), but can contain a limited number of filters.The driver uses the "objagg" library to perform the mask aggregation bypassing it objects that consist of the filter's mask and whether thefilter is to be inserted into the A-TCAM or the C-TCAM since filters indifferent TCAMs cannot share a mask.The set of created objects is dependent on the insertion order of thefilters and is not necessarily optimal. Therefore, the driver willperiodically ask the library to compute a more optimal set ("hints") bylooking at all the existing objects.When the library asks the driver whether two objects can be aggregatedthe driver only compares the provided masks and ignores the A-TCAM /C-TCAM indication. This is the right thing to do since the goal is tomove as many filters as possible to the A-TCAM. The driver also forbidstwo identical masks from being aggregated since this can only happen ifone was intentionally put in the C-TCAM to avoid a conflict in theA-TCAM.The above can result in the following set of hints:H1: {mask X, A-TCAM} -> H2: {mask Y, A-TCAM} // X is Y + deltaH3: {mask Y, C-TCAM} -> H4: {mask Z, A-TCAM} // Y is Z + deltaAfter getting the hints from the library the driver will start migratingfilters from one region to another while consulting the computed hintsand instructing the device to perform a lookup in both regions duringthe transition.Assuming a filter with mask X is being migrated into the A-TCAM in thenew region, the hints lookup will return H1. Since H2 is the parent ofH1, the library will try to find the object associated with it andcreate it if necessary in which case another hints lookup (recursive)will be performed. This hints lookup for {mask Y, A-TCAM} will eitherreturn H2 or H3 since the driver passes the library an object comparisonfunction that ignores the A-TCAM / C-TCAM indication.This can eventually lead to nested objects which are not supported bythe library [1].Fix by removing the object comparison function from both the driver andthe library as the driver was the only user. That way the lookup willonly return exact matches.I do not have a reliable reproducer that can reproduce the issue in atimely manner, but before the fix the issue would reproduce in severalminutes and with the fix it does not reproduce in over an hour.Note that the current usefulness of the hints is limited because theyinclude the C-TCAM indication and represent aggregation that cannotactually happen. This will be addressed in net-next.[1]WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0Modules linked in:CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_workRIP: 0010:objagg_obj_parent_assign+0xb5/0xd0[...]Call Trace: __objagg_obj_get+0x2bb/0x580 objagg_obj_get+0xe/0x80 mlxsw_sp_acl_erp_mask_get+0xb5/0xf0 mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 process_one_work+0x151/0x370

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null pointer deref in dcn20_resource.cFixes a hang thats triggered when MPV is run on a DCN401 dGPU:mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=alland then enabling fullscreen playback (double click on the video)The following calltrace will be seen:[ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 181.843997] #PF: supervisor instruction fetch in kernel mode[ 181.844003] #PF: error_code(0x0010) - not-present page[ 181.844009] PGD 0 P4D 0[ 181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI[ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu[ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018[ 181.844044] RIP: 0010:0x0[ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6.[ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246[ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004[ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400[ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c[ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8[ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005[ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000[ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0[ 181.844141] Call Trace:[ 181.844146] [ 181.844153] ? show_regs+0x6d/0x80[ 181.844167] ? __die+0x24/0x80[ 181.844179] ? page_fault_oops+0x99/0x1b0[ 181.844192] ? do_user_addr_fault+0x31d/0x6b0[ 181.844204] ? exc_page_fault+0x83/0x1b0[ 181.844216] ? asm_exc_page_fault+0x27/0x30[ 181.844237] dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu][ 181.845115] amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu][ 181.845985] amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu][ 181.846848] fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu][ 181.847734] fill_dc_plane_attributes+0x162/0x350 [amdgpu][ 181.848748] dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu][ 181.849791] ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu][ 181.850840] amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-43909 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu/pm: Fix the null pointer dereference for smu7optimize the code to avoid pass a null pointer (hwmgr->backend)to function smu7_update_edc_leakage_table.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: prevent potential speculation leaks in gpio_device_get_desc()Userspace may trigger a speculative read of an address outside the gpiodescriptor array.Users can do that by calling gpio_ioctl() with an offset out of range.Offset is copied from user and then used as an array index to getthe gpio descriptor without sanitization in gpio_device_get_desc().This change ensures that the offset is sanitized by usingarray_index_nospec() to mitigate any possibility of speculativeinformation leaks.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44934 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: mcast: wait for previous gc cycles when removing portsyzbot hit a use-after-free[1] which is caused because the bridge doesn'tmake sure that all previous garbage has been collected when removing aport. What happens is: CPU 1 CPU 2 start gc cycle remove port acquire gc lock first wait for lock call br_multicasg_gc() directly acquire lock now but free port the port can be freed while grp timers still runningMake sure all previous gc cycles have finished by using flush_work beforefreeing the port.[1] BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699 CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792 expire_timers kernel/time/timer.c:1843 [inline] __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417 __run_timer_base kernel/time/timer.c:2428 [inline] __run_timer_base kernel/time/timer.c:2421 [inline] run_timer_base+0x111/0x190 kernel/time/timer.c:2437

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44935 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Fix null-ptr-deref in reuseport_add_sock().syzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb inreuseport_add_sock(). [0]The repro first creates a listener with SO_REUSEPORT. Then, it createsanother listener on the same port and concurrently closes the firstlistener.The second listen() calls reuseport_add_sock() with the first listener assk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently,but the close() does clear it by reuseport_detach_sock().The problem is SCTP does not properly synchronise reuseport_alloc(),reuseport_add_sock(), and reuseport_detach_sock().The caller of reuseport_alloc() and reuseport_{add,detach}_sock() mustprovide synchronisation for sockets that are classified into the samereuseport group.Otherwise, such sockets form multiple identical reuseport groups, andall groups except one would be silently dead. 1. Two sockets call listen() concurrently 2. No socket in the same group found in sctp_ep_hashtable[] 3. Two sockets call reuseport_alloc() and form two reuseport groups 4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives incoming packetsAlso, the reported null-ptr-deref could occur.TCP/UDP guarantees that would not happen by holding the hash bucket lock.Let's apply the locking strategy to __sctp_hash_endpoint() and__sctp_unhash_endpoint().[0]:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __sctp_hash_endpoint net/sctp/input.c:762 [inline] sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790 sctp_listen_start net/sctp/socket.c:8570 [inline] sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625 __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline] __se_sys_listen net/socket.c:1900 [inline] __x64_sys_listen+0x5a/0x70 net/socket.c:1900 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/0x7fRIP: 0033:0x7f24e46039b9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 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:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42cR13:---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44939 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix null ptr deref in dtInsertEntry[syzbot reported]general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713...[Analyze]In dtInsertEntry(), when the pointer h has the same value as p, after writingname in UniStrncpy_to_le(), p->header.flag will be cleared. This will cause thepreviously true judgment "p->header.flag & BT-LEAF" to change to no after writingthe name operation, this leads to entering an incorrect branch and accessing theuninitialized object ih when judging this condition for the second time.[Fix]After got the page, check freelist first, if freelist == 0 then exit dtInsert()and return -EINVAL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44944 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: use helper function to calculate expect IDDelete expectation path is missing a call to the nf_expect_get_id()helper function to calculate the expectation ID, otherwise LSB of theexpectation object address is leaked to userspace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44948 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mtrr: Check if fixed MTRRs exist before saving themMTRRs have an obsolete fixed variant for fine grained caching controlof the 640K-1MB region that uses separate MSRs. This fixed variant hasa separate capability bit in the MTRR capability MSR.So far all x86 CPUs which support MTRR have this separate bit set, so itwent unnoticed that mtrr_save_state() does not check the capability bitbefore accessing the fixed MTRR MSRs.Though on a CPU that does not support the fixed MTRR capability thisresults in a #GP. The #GP itself is harmless because the RDMSR fault ishandled gracefully, but results in a WARN_ON().Add the missing capability check to prevent this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44950 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: fix invalid FIFO access with special register setWhen enabling access to the special register set, Receiver time-out andRHR interrupts can happen. In this case, the IRQ handler will try to readfrom the FIFO thru the RHR register at address 0x00, but address 0x00 ismapped to DLL register, resulting in erroneous FIFO reading.Call graph example: sc16is7xx_startup(): entry sc16is7xx_ms_proc(): entry sc16is7xx_set_termios(): entry sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set sc16is7xx_port_irq() entry --> IIR is 0x0C sc16is7xx_handle_rx() entry sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is mapped to DLL (LCR=LCR_CONF_MODE_A) sc16is7xx_set_baud(): exit --> Restore access to general register setFix the problem by claiming the efr_lock mutex when accessing the Specialregister set.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44954 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: line6: Fix racy access to midibufThere can be concurrent accesses to line6 midibuf from both the URBcompletion callback and the rawmidi API access. This could be a causeof KMSAN warning triggered by syzkaller below (so put as reported-byhere).This patch protects the midibuf call of the former code path with aspinlock for avoiding the possible races.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44958 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/smt: Fix unbalance sched_smt_present dec/incI got the following warn report while doing stress test:jump label: negative count!WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0Call Trace: __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret_from_fork+0x41/0x70 ret_from_fork_asm+0x1b/0x30 Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),the cpu offline failed, but sched_smt_present is decremented beforecalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, sofix it by incrementing sched_smt_present in the error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44969 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Prevent release of buffer in I/OWhen a task waiting for completion of a Store Data operation isinterrupted, an attempt is made to halt this operation. If this attemptfails due to a hardware or firmware problem, there is a chance that theSCLP facility might store data into buffers referenced by the originaloperation at a later time.Handle this situation by not releasing the referenced data buffers ifthe halt attempt fails. For current use cases, this might result in aleak of few pages of memory in case of a rare hardware/firmwaremalfunction.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44971 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()bcm_sf2_mdio_register() calls of_phy_find_device() and thenphy_device_remove() in a loop to remove existing PHY devices.of_phy_find_device() eventually calls bus_find_device(), which callsget_device() on the returned struct device * to increment the refcount.The current implementation does not decrement the refcount, which causesmemory leak.This commit adds the missing phy_device_free() call to decrement therefcount via put_device() to balance the refcount.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dpu: cleanup FB if dpu_format_populate_layout failsIf the dpu_format_populate_layout() fails, then FB is prepared, but notcleaned up. This ends up leaking the pin_count on the GEM object andcauses a splat during DRM file closure:msm_obj->pin_countWARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc[...]Call trace: update_lru_locked+0xc4/0xcc put_pages+0xac/0x100 msm_gem_free_object+0x138/0x180 drm_gem_object_free+0x1c/0x30 drm_gem_object_handle_put_unlocked+0x108/0x10c drm_gem_object_release_handle+0x58/0x70 idr_for_each+0x68/0xec drm_gem_release+0x28/0x40 drm_file_free+0x174/0x234 drm_release+0xb0/0x160 __fput+0xc0/0x2c8 __fput_sync+0x50/0x5c __arm64_sys_close+0x38/0x7c invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x4c/0x120 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194irq event stamp: 129818hardirqs last enabled at (129817): [] console_unlock+0x118/0x124hardirqs last disabled at (129818): [] el1_dbg+0x24/0x8csoftirqs last enabled at (129808): [] handle_softirqs+0x4c8/0x4e8softirqs last disabled at (129785): [] __do_softirq+0x14/0x20Patchwork: https://patchwork.freedesktop.org/patch/600714/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44986 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix possible UAF in ip6_finish_output2()If skb_expand_head() returns NULL, skb has been freedand associated dst/idev could also have been freed.We need to hold rcu_read_lock() to make sure the dst andassociated idev are alive.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44988 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: Fix out-of-bound accessIf an ATU violation was caused by a CPU Load operation, the SPID couldbe larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44989 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: fix xfrm real_dev null pointer dereferenceWe shouldn't set real_dev to NULL because packets can be in transit andxfrm might call xdo_dev_offload_ok() in parallel. All callbacks assumereal_dev is set. Example trace: kernel: BUG: unable to handle page fault for address: 0000000000001030 kernel: bond0: (slave eni0np1): making interface the new active one kernel: #PF: supervisor write access in kernel mode kernel: #PF: error_code(0x0002) - not-present page kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (slave eni0np1): making interface the new active one kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014 kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (slave eni0np1): making interface the new active one kernel: Call Trace: kernel: kernel: ? __die+0x1f/0x60 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? page_fault_oops+0x142/0x4c0 kernel: ? do_user_addr_fault+0x65/0x670 kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50 kernel: bond0: (slave eni0np1): making interface the new active one kernel: ? exc_page_fault+0x7b/0x180 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): making interface the new active one kernel: bond_ipsec_offload_ok+0x7b/0x90 [bonding] kernel: xfrm_output+0x61/0x3b0 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ip_push_pending_frames+0x56/0x80

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44990 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: fix null pointer deref in bond_ipsec_offload_okWe must check if there is an active slave before dereferencing the pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44995 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix a deadlock problem when config TC during resettingWhen config TC during the reset process, may cause a deadlock, the flow isas below: pf reset start | v ......setup tc | | v v DOWN: napi_disable()napi_disable()(skip) | | | v v ...... ...... | | v |napi_enable() | v UINIT: netif_napi_del() | v ...... | v INIT: netif_napi_add() | v ...... global reset start | | v v UP: napi_enable()(skip) ...... | | v v ...... napi_disable()In reset process, the driver will DOWN the port and then UINIT, in thiscase, the setup tc process will UP the port before UINIT, so cause theproblem. Adds a DOWN process in UINIT to fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44998 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: idt77252: prevent use after free in dequeue_rx()We can't dereference "skb" after calling vcc->push() because the skbis released.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-44999 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: pull network headers in gtp_dev_xmit()syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]We must make sure the IPv4 or Ipv6 header is pulled in skb->headbefore accessing fields in them.Use pskb_inet_may_pull() to fix this issue.[1]BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [inline] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit include/linux/netdevice.h:4913 [inline] netdev_start_xmit include/linux/netdevice.h:4922 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit include/linux/netdevice.h:3105 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3145 [inline] packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:3994 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [inline] packet_snd net/packet/af_packet.c:3088 [inline] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-45007 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:char: xillybus: Don't destroy workqueue from work item running on itTriggered by a kref decrement, destroy_workqueue() may be called fromwithin a work item for destroying its own workqueue. This illegalsituation is averted by adding a module-global workqueue for exclusiveuse of the offending work item. Other work items continue to be queuedon per-device workqueues to ensure performance.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-45008 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: MT - limit max slotssyzbot is reporting too large allocation at input_mt_init_slots(), fornum_slots is supplied from userspace using ioctl(UI_DEV_CREATE).Since nobody knows possible max slots, this patch chose 1024.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-45011 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:char: xillybus: Check USB endpoints when probing deviceEnsure, as the driver probes the device, that all endpoints that thedriver may attempt to access exist and are of the correct type.All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint ataddress 1. This is verified in xillyusb_setup_base_eps().On top of that, a XillyUSB device may have additional Bulk OUTendpoints. The information about these endpoints' addresses is deducedfrom a data structure (the IDT) that the driver fetches from the devicewhile probing it. These endpoints are checked in setup_channels().A XillyUSB device never has more than one IN endpoint, as all datatowards the host is multiplexed in this single Bulk IN endpoint. This iswhy setup_channels() only checks OUT endpoints.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-45018 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: initialise extack before useFix missing initialisation of extack in flow offload.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-45025 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHAREcopy_fd_bitmaps(new, old, count) is expected to copy the firstcount/BITS_PER_LONG bits from old->full_fds_bits[] and fillthe rest with zeroes. What it does is copying enough words(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.That works fine, *if* all bits past the cutoff point areclear. Otherwise we are risking garbage from the last wordwe'd copied.For most of the callers that is true - expand_fdtable() hascount equal to old->max_fds, so there's no open descriptorspast count, let alone fully occupied words in ->open_fds[],which is what bits in ->full_fds_bits[] correspond to.The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),which is the smallest multiple of BITS_PER_LONG that covers allopened descriptors below max_fds. In the common case (copying onfork()) max_fds is ~0U, so all opened descriptors will be belowit and we are fine, by the same reasons why the call in expand_fdtable()is safe.Unfortunately, there is a case where max_fds is less than thatand where we might, indeed, end up with junk in ->full_fds_bits[] -close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors.In that case we end up with observably wrong behaviour - e.g. spawna child with CLONE_FILES, get all descriptors in range 0..127 open,then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) endingup with descriptor #128, despite #64 being observably not open.The minimally invasive fix would be to deal with that in dup_fd().If this proves to add measurable overhead, we can go that way, butlet's try to fix copy_fd_bitmaps() first.* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).* make copy_fd_bitmaps() take the bitmap size in words, rather thanbits; it's 'count' argument is always a multiple of BITS_PER_LONG,so we are not losing any information, and that way we can use thesame helper for all three bitmaps - compiler will see that countis a multiple of BITS_PER_LONG for the large ones, so it'll generateplain memcpy()+memset().Reproducer added to tools/testing/selftests/core/close_range_test.c

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-45029 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: tegra: Do not mark ACPI devices as irq safeOn ACPI machines, the tegra i2c module encounters an issue due to amutex being called inside a spinlock. This leads to the following bug: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585 ... Call trace: __might_sleep __mutex_lock_common mutex_lock_nested acpi_subsys_runtime_resume rpm_resume tegra_i2c_xferThe problem arises because during __pm_runtime_resume(), the spinlock&dev->power.lock is acquired before rpm_resume() is called. Later,rpm_resume() invokes acpi_subsys_runtime_resume(), which relies onmutexes, triggering the error.To address this issue, devices on ACPI are now marked as not IRQ-safe,considering the dependency of acpi_subsys_runtime_resume() on mutexes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46677 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: fix a potential NULL pointer dereferenceWhen sockfd_lookup() fails, gtp_encap_enable_socket() returns aNULL pointer, but its callers only check for error pointers thus missthe NULL pointer case.Fix it by returning an error pointer with the error code carried fromsockfd_lookup().(I found this bug during code inspection.)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46685 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: single: fix potential NULL dereference in pcs_get_function()pinmux_generic_get_function() can return NULL and the pointer 'function'was dereferenced without checking against NULL. Add checking of pointer'function' in pcs_get_function().Found by code review.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46686 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req()This happens when called from SMB2_read() while using rdmaand reaching the rdma_readwrite_threshold.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46689 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: cmd-db: Map shared memory as WC, not WBLinux does not write into cmd-db region. This region of memory is writeprotected by XPU. XPU may sometime falsely detect clean cache evictionas "write" into the write protected region leading to secure interruptwhich causes an endless loop somewhere in Trust Zone.The only reason it is working right now is because Qualcomm Hypervisormaps the same region as Non-Cacheable memory in Stage 2 translationtables. The issue manifests if we want to use another hypervisor (likeXen or KVM), which does not know anything about those specific mappings.Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WCremoves dependency on correct mappings in Stage 2 tables. This patchfixes the issue by updating the mapping to MEMREMAP_WC.I tested this on SA8155P with Xen.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46695 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:selinux,smack: don't bypass permissions check in inode_setsecctx hookMarek Gresko reports that the root user on an NFS client is able tochange the security labels on files on an NFS filesystem that isexported with root squashing enabled.The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks.nfsd_setattr() does do permissions checking via fh_verify() andnfsd_permission(), but those don't do all the same permissions checksthat are done by security_inode_setxattr() and its related LSM hooks do.Since nfsd_setattr() is the only consumer of security_inode_setsecctx(),simplest solution appears to be to replace the call to__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). Thisfixes the above issue and has the added benefit of causing nfsd torecall conflicting delegations on a file when a client tries to changeits security label.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46707 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3On a system with a GICv3, if a guest hasn't been configured withGICv3 and that the host is not capable of GICv2 emulation,a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.We therefore try to emulate the SGI access, only to hit a NULLpointer as no private interrupt is allocated (no GIC, remember?).The obvious fix is to give the guest what it deserves, in theshape of a UNDEF exception.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46713 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/aux: Fix AUX buffer serializationOle reported that event->mmap_mutex is strictly insufficient toserialize the AUX buffer, add a per RB mutex to fully serialize it.Note that in the lock order comment the perf_event::mmap_mutex orderwas already wrong, that is, it nesting under mmap_lock is not new withthis patch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46714 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Skip wbscl_set_scaler_filter if filter is nullCallers can pass null in filter (i.e. from returned from the functionwbscl_get_filter_coeffs_16p) and a null check is added to ensure that isnot the case.This fixes 4 NULL_RETURNS issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46715 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:driver: iio: add missing checks on iio_info's callback accessSome callbacks from iio_info structure are accessed without any check, soif a driver doesn't implement them trying to access the correspondingsysfs entries produce a kernel oops such as:[ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute[...][ 2203.783416] Call trace:[ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48[ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120[ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4[ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0[ 2203.802236] vfs_read from ksys_read+0xa4/0xd4[ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54[ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0)[ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000[ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000[ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0[ 2203.830363] Code: bad PC value[ 2203.832695] ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46717 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: SHAMPO, Fix incorrect page releaseUnder the following conditions:1) No skb created yet2) header_size == 0 (no SHAMPO header)3) header_index + 1 % MLX5E_SHAMPO_WQ_HEADER_PER_PAGE == 0 (this is the last page fragment of a SHAMPO header page)a new skb is formed with a page that is NOT a SHAMPO header page (itis a regular data page). Further down in the same function(mlx5e_handle_rx_cqe_mpwrq_shampo()), a SHAMPO header page fromheader_index is released. This is wrong and it leads to SHAMPO headerpages being released more than once.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46721 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix possible NULL pointer dereferenceprofile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is madefrom __create_missing_ancestors(..) and 'ent->old' is NULL inaa_replace_profiles(..).In that case, it must return an error code and the code, -ENOENT representsits state that the path of its parent is not existed yet.BUG: kernel NULL pointer dereference, address: 0000000000000030PGD 0 P4D 0PREEMPT SMP PTICPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014RIP: 0010:aafs_create.constprop.0+0x7f/0x130Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a aeRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0Call Trace: ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? kernelmode_fixup_or_oops+0xb2/0x140 ? __bad_area_nosemaphore+0x1a5/0x2c0 ? find_vma+0x34/0x60 ? bad_area_nosemaphore+0x16/0x30 ? do_user_addr_fault+0x2a2/0x6b0 ? exc_page_fault+0x83/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? aafs_create.constprop.0+0x7f/0x130 ? aafs_create.constprop.0+0x51/0x130 __aafs_profile_mkdir+0x3d6/0x480 aa_replace_profiles+0x83f/0x1270 policy_update+0xe3/0x180 profile_load+0xbc/0x150 ? rw_verify_area+0x47/0x140 vfs_write+0x100/0x480 ? __x64_sys_openat+0x55/0xa0 ? syscall_exit_to_user_mode+0x86/0x260 ksys_write+0x73/0x100 __x64_sys_write+0x19/0x30 x64_sys_call+0x7e/0x25c0 do_syscall_64+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x78/0x80RIP: 0033:0x7be9f211c574Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30 Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesasCR2: 0000000000000030---[ end trace 0000000000000000 ]---RIP: 0010:aafs_create.constprop.0+0x7f/0x130Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a aeRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000R10: 0000---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46722 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix mc_data out-of-bounds read warningClear warning that read mc_data[i-1] may out-of-bounds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46723 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix ucode out-of-bounds read warningClear warning that read ucode[] may out-of-bounds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46724 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_numberCheck the fb_channel_number range to avoid the array out-of-boundsread error

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46725 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix out-of-bounds write warningCheck the ring type value to fix the out-of-boundswrite warning

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46731 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix the Out-of-bounds read warningusing index i - 1U may beyond element indexfor mc_data[] when i = 0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46732 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Assign linear_pitch_alignment even for VM[Description]Assign linear_pitch_alignment so we don't cause a divide by 0error in VM environments

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46744 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: sanity check symbolic link sizeSyzkiller reports a "KMSAN: uninit-value in pick_link" bug.This is caused by an uninitialised page, which is ultimately causedby a corrupted symbolic link size read from disk.The reason why the corrupted symlink size causes an uninitialisedpage is due to the following sequence of events:1. squashfs_read_inode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size.2. Later squashfs_symlink_read_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number.3. The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page.This patch adds a sanity check which checks that the symboliclink size is not larger than expected.--V2: fix spelling mistake.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46745 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: uinput - reject requests with unreasonable number of slotsWhen exercising uinput interface syzkaller may try setting up devicewith a really large number of slots, which causes memory allocationfailure in input_mt_init_slots(). While this allocation failure ishandled properly and request is rejected, it results in syzkallerreports. Additionally, such request may put undue burden on thesystem which will try to free a lot of memory for a bogus request.Fix it by limiting allowed number of slots to 100. This can easilybe extended if we see devices that can track more than 100 contacts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46751 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info()Instead of doing a BUG_ON() handle the error by returning -EUCLEAN,aborting the transaction and logging an error message.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46752 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: replace BUG_ON() with error handling at update_ref_for_cow()Instead of a BUG_ON() just return an error, log an error message andabort the transaction in case we find an extent buffer belonging to therelocation tree that doesn't have the full backref flag set. This isunexpected and should never happen (save for bugs or a potential badmemory).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46753 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: handle errors from btrfs_dec_ref() properlyIn walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref(). This isincorrect, we have proper error handling here, return the error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46755 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()mwifiex_get_priv_by_id() returns the priv pointer corresponding tothe bss_num and bss_type, but without checking if the priv is actuallycurrently in use.Unused priv pointers do not have a wiphy attached to them which canlead to NULL pointer dereferences further down the callstack. Fixthis by returning only used priv pointers which have priv->bss_modeset to something else than NL80211_IFTYPE_UNSPECIFIED.Said NULL pointer dereference happened when an Accesspoint was startedwith wpa_supplicant -i mlan0 with this config:network={ ssid="somessid" mode=2 frequency=2412 key_mgmt=WPA-PSK WPA-PSK-SHA256 proto=RSN group=CCMP pairwise=CCMP psk="12345678"}When waiting for the AP to be established, interrupting wpa_supplicantwith and starting it again this happens:| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140| Mem abort info:| ESR = 0x0000000096000004| EC = 0x25: DABT (current EL), IL = 32 bits| SET = 0, FnV = 0| EA = 0, S1PTW = 0| FSC = 0x04: level 0 translation fault| Data abort info:| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000| CM = 0, WnR = 0, TnD = 0, TagAccess = 0| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18| Hardware name: somemachine (DT)| Workqueue: events sdio_irq_work| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]| sp : ffff8000818b3a70| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000| Call trace:| mwifiex_get_cfp+0xd8/0x15c [mwifiex]| mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]| mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]| mwifiex_process_sta_event+0x298/0xf0c [mwifiex]| mwifiex_process_event+0x110/0x238 [mwifiex]| mwifiex_main_process+0x428/0xa44 [mwifiex]| mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]| process_sdio_pending_irqs+0x64/0x1b8| sdio_irq_work+0x4c/0x7c| process_one_work+0x148/0x2a0| worker_thread+0x2fc/0x40c| kthread+0x110/0x114| ret_from_fork+0x10/0x20| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)| ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46761 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pci/hotplug/pnv_php: Fix hotplug driver crash on PowernvThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernelcrash when we try to hot-unplug/disable the PCIe switch/bridge fromthe PHB.The crash occurs because although the MSI data structure has beenreleased during disable/hot-unplug path and it has been assignedwith NULL, still during unregistration the code was again trying toexplicitly disable the MSI which causes the NULL pointer dereference andkernel crash.The patch fixes the check during unregistration path to prevent invokingpci_disable_msi/msix() since its data structure is already freed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46765 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: protect XDP configuration with a mutexThe main threat to data consistency in ice_xdp() is a possible asynchronousPF reset. It can be triggered by a user or by TX timeout handler.XDP setup and PF reset code access the same resources in the followingsections:* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked* ice_vsi_rebuild() for the PF VSI - not protected* ice_vsi_open() - already rtnl-lockedWith an unfortunate timing, such accesses can result in a crash such as theone below:[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14[ +0.394718] ice 0000:b1:00.0: PTP reset successful[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098[ +0.000045] #PF: supervisor read access in kernel mode[ +0.000023] #PF: error_code(0x0000) - not-present page[ +0.000023] PGD 0 P4D 0[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021[ +0.000036] Workqueue: ice ice_service_task [ice][ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice][...][ +0.000013] Call Trace:[ +0.000016] [ +0.000014] ? __die+0x1f/0x70[ +0.000029] ? page_fault_oops+0x171/0x4f0[ +0.000029] ? schedule+0x3b/0xd0[ +0.000027] ? exc_page_fault+0x7b/0x180[ +0.000022] ? asm_exc_page_fault+0x22/0x30[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice][ +0.000194] ice_free_tx_ring+0xe/0x60 [ice][ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice][ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice][ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice][ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice][ +0.000145] ice_rebuild+0x18c/0x840 [ice][ +0.000145] ? delay_tsc+0x4a/0xc0[ +0.000022] ? delay_tsc+0x92/0xc0[ +0.000020] ice_do_reset+0x140/0x180 [ice][ +0.000886] ice_service_task+0x404/0x1030 [ice][ +0.000824] process_one_work+0x171/0x340[ +0.000685] worker_thread+0x277/0x3a0[ +0.000675] ? preempt_count_add+0x6a/0xa0[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50[ +0.000679] ? __pfx_worker_thread+0x10/0x10[ +0.000653] kthread+0xf0/0x120[ +0.000635] ? __pfx_kthread+0x10/0x10[ +0.000616] ret_from_fork+0x2d/0x50[ +0.000612] ? __pfx_kthread+0x10/0x10[ +0.000604] ret_from_fork_asm+0x1b/0x30[ +0.000604] The previous way of handling this through returning -EBUSY is not viable,particularly when destroying AF_XDP socket, because the kernel proceedswith removal anyway.There is plenty of code between those calls and there is no need to createa large critical section that covers all of them, same as there is no needto protect ice_vsi_rebuild() with rtnl_lock().Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().Leaving unprotected sections in between would result in two states thathave to be considered:1. when the VSI is closed, but not yet rebuild2. when VSI is already rebuild, but not yet openThe latter case is actually already handled through !netif_running() case,we just need to adjust flag checking a little. The former one is not astrivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot ofhardware interaction happens, this can make adding/deleting rings exitwith an error. Luckily, VSI rebuild is pending and can apply newconfiguration for us in a managed fashion.Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING toindicate that ice_x---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46770 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Add netif_device_attach/detach into PF reset flowEthtool callbacks can be executed while reset is in progress and try toaccess deleted resources, e.g. getting coalesce settings can result in aNULL pointer dereference seen below.Reproduction steps:Once the driver is fully initialized, trigger reset: # echo 1 > /sys/class/net//device/resetwhen reset is in progress try to get coalesce settings using ethtool: # ethtool -c BUG: kernel NULL pointer dereference, address: 0000000000000020PGD 0 P4D 0Oops: Oops: 0000 [#1] PREEMPT SMP PTICPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0Call Trace:ice_get_coalesce+0x17/0x30 [ice]coalesce_prepare_data+0x61/0x80ethnl_default_doit+0xde/0x340genl_family_rcv_msg_doit+0xf2/0x150genl_rcv_msg+0x1b3/0x2c0netlink_rcv_skb+0x5b/0x110genl_rcv+0x28/0x40netlink_unicast+0x19c/0x290netlink_sendmsg+0x222/0x490__sys_sendto+0x1df/0x1f0__x64_sys_sendto+0x24/0x30do_syscall_64+0x82/0x160entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7faee60d8e27Calling netif_device_detach() before reset makes the net core not callthe driver when ethtool command is issued, the attempt to execute anethtool command during reset will result in the following message: netlink error: No such deviceinstead of NULL pointer dereference. Once reset is done andice_rebuild() is executing, the netif_device_attach() is called to allowfor ethtool operations to occur again in a safe manner.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46771 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: Remove proc entry when dev is unregistered.syzkaller reported a warning in bcm_connect() below. [0]The repro calls connect() to vxcan1, removes vxcan1, and callsconnect() with ifindex == 0.Calling connect() for a BCM socket allocates a proc entry.Then, bcm_sk(sk)->bound is set to 1 to prevent further connect().However, removing the bound device resets bcm_sk(sk)->bound to 0in bcm_notify().The 2nd connect() tries to allocate a proc entry with the samename and sets NULL to bcm_sk(sk)->bcm_proc_read, leaking theoriginal proc entry.Since the proc entry is available only for connect()ed sockets,let's clean up the entry when the bound netdev is unregistered.[0]:proc_dir_entry 'can-bcm/2456' already registeredWARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375Modules linked in:CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 <0f> 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ecFS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400PKRU: 55555554Call Trace: proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220 bcm_connect+0x472/0x840 net/can/bcm.c:1673 __sys_connect_file net/socket.c:2049 [inline] __sys_connect+0x5d2/0x690 net/socket.c:2066 __do_sys_connect net/socket.c:2076 [inline] __se_sys_connect net/socket.c:2073 [inline] __x64_sys_connect+0x8f/0x100 net/socket.c:2073 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7fbd708b0e5dCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5dRDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000 remove_proc_entry: removing non-empty directory 'net/can-bcm', leaking at least '2456'

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46777 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udf: Avoid excessive partition lengthsAvoid mounting filesystems where the partition would overflow the32-bits used for block number. Also refuse to mount filesystems wherethe partition length is so large we cannot safely index bits in ablock bitmap.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46780 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: protect references to superblock parameters exposed in sysfsThe superblock buffers of nilfs2 can not only be overwritten at runtimefor modifications/repairs, but they are also regularly swapped, replacedduring resizing, and even abandoned when degrading to one side due tobacking device issues. So, accessing them requires mutual exclusion usingthe reader/writer semaphore "nilfs->ns_sem".Some sysfs attribute show methods read this superblock buffer without thenecessary mutual exclusion, which can cause problems with pointerdereferencing and memory access, so fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46781 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix missing cleanup on rollforward recovery errorIn an error injection test of a routine for mount-time recovery, KASANfound a use-after-free bug.It turned out that if data recovery was performed using partial logscreated by dsync writes, but an error occurred before starting the logwriter to create a recovered checkpoint, the inodes whose data had beenrecovered were left in the ns_dirty_files list of the nilfs object andwere not freed.Fix this issue by cleaning up inodes that have read the recovery data ifthe recovery routine fails midway before the log writer starts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46782 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ila: call nf_unregister_net_hooks() soonersyzbot found an use-after-free Read in ila_nf_input [1]Issue here is that ila_xlat_exit_net() frees the rhashtable,then call nf_unregister_net_hooks().It should be done in the reverse way, with a synchronize_rcu().This is a good match for a pre_exit() method.[1] BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline] BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline] BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup include/linux/rhashtable.h:604 [inline] rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6108 __napi_poll+0xcb/0x490 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6963 handle_softirqs+0x2c4/0x970 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:928 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)page_type: 0xbfffffff(buddy)raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as freedpage last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493 prep_new_page mm/page_alloc.c:1501 [inline] get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695 __alloc_pages_node_noprof include/linux/gfp.h:269 [inline] alloc_pages_node_noprof include/linux/gfp.h:296 [inline] ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103 __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130 __do_kmalloc_node mm/slub.c:4146 [inline] __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164 __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650 bucket_table_alloc lib/rhashtable.c:186 [inline] rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071 ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613 ops_ini---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46783 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: fix return value of tcp_bpf_sendmsg()When we cork messages in psock->cork, the last message triggers theflushing will result in sending a sk_msg larger than the currentmessage size. In this case, in tcp_bpf_send_verdict(), 'copied' becomesnegative at least in the following case:468 case __SK_DROP:469 default:470 sk_msg_free_partial(sk, msg, tosend);471 sk_msg_apply_bytes(psock, tosend);472 *copied -= (tosend + delta); // <==== HERE473 return -EACCES;Therefore, it could lead to the following BUG with a proper value of'copied' (thanks to syzbot). We should not use negative 'copied' as areturn value here. ------------[ cut here ]------------ kernel BUG at net/socket.c:733! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0 Hardware name: linux,dummy-virt (DT) pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : sock_sendmsg_nosec net/socket.c:733 [inline] pc : sock_sendmsg_nosec net/socket.c:728 [inline] pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745 lr : sock_sendmsg_nosec net/socket.c:730 [inline] lr : __sock_sendmsg+0x54/0x60 net/socket.c:745 sp : ffff800088ea3b30 x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000 x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000 x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90 x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001 x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0 x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000 x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef Call trace: sock_sendmsg_nosec net/socket.c:733 [inline] __sock_sendmsg+0x5c/0x60 net/socket.c:745 ____sys_sendmsg+0x274/0x2ac net/socket.c:2597 ___sys_sendmsg+0xac/0x100 net/socket.c:2651 __sys_sendmsg+0x84/0xe0 net/socket.c:2680 __do_sys_sendmsg net/socket.c:2689 [inline] __se_sys_sendmsg net/socket.c:2687 [inline] __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151 el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598 Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000) ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:userfaultfd: fix checks for huge PMDsPatch series "userfaultfd: fix races around pmd_trans_huge() check", v2.The pmd_trans_huge() code in mfill_atomic() is wrong in three differentways depending on kernel version:1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case).2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr().3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong.I decided to write two separate fixes for these (one fix for bugs 1+2, onefix for bug 3), so that the first fix can be backported to kernelsaffected by bugs 1+2.This patch (of 2):This fixes two issues.I discovered that the following race can occur: mfill_atomic other thread ============ ============ pmdp_get_lockless() [reads none pmd] __pte_alloc [no-op] BUG_ON(pmd_none(*dst_pmd))I have experimentally verified this in a kernel with extra mdelay() calls;the BUG_ON(pmd_none(*dst_pmd)) triggers.On kernels newer than commit 0d940a9b270b ("mm/pgtable: allowpte_offset_map[_lock]() to fail"), this can't lead to anything worse thana BUG_ON(), since the page table access helpers are actually designed todeal with page tables concurrently disappearing; but on older kernels(<=6.4), I think we could probably theoretically race past the twoBUG_ON() checks and end up treating a hugepage as a page table.The second issue is that, as Qi Zheng pointed out, there are other typesof huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs(in particular, migration PMDs).On <=6.4, this is worse than the first issue: If mfill_atomic() runs on aPMD that contains a migration entry (which just requires winning a single,fairly wide race), it will pass the PMD to pte_offset_map_lock(), whichassumes that the PMD points to a page table.Breakage follows: First, the kernel tries to take the PTE lock (which willcrash or maybe worse if there is no "struct page" for the address bits inthe migration entry PMD - I think at least on X86 there usually is nocorresponding "struct page" thanks to the PTE inversion mitigation, amd64looks different).If that didn't crash, the kernel would next try to write a PTE into whatit wrongly thinks is a page table.As part of fixing these issues, get rid of the check for pmd_trans_huge()before __pte_alloc() - that's redundant, we're going to have to check forthat after the __pte_alloc() anyway.Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46791 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_openThe mcp251x_hw_wake() function is called with the mpc_lock mutex held anddisables the interrupt handler so that no interrupts can be processed whilewaking the device. If an interrupt has already occurred then waiting forthe interrupt handler to complete will deadlock because it will be tryingto acquire the same mutex.CPU0 CPU1---- ----mcp251x_open() mutex_lock(&priv->mcp_lock) request_threaded_irq() mcp251x_can_ist() mutex_lock(&priv->mcp_lock) mcp251x_hw_wake() disable_irq() <-- deadlockUse disable_irq_nosync() instead because the interrupt handler doeseverything while holding the mutex so it doesn't matter if it's stillrunning.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46798 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: dapm: Fix UAF for snd_soc_pcm_runtime objectWhen using kernel with the following extra config, - CONFIG_KASAN=y - CONFIG_KASAN_GENERIC=y - CONFIG_KASAN_INLINE=y - CONFIG_KASAN_VMALLOC=y - CONFIG_FRAME_WARN=4096kernel detects that snd_pcm_suspend_all() access a freed'snd_soc_pcm_runtime' object when the system is suspended, whichleads to a use-after-free bug:[ 52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270[ 52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330[ 52.047785] Call trace:[ 52.047787] dump_backtrace+0x0/0x3c0[ 52.047794] show_stack+0x34/0x50[ 52.047797] dump_stack_lvl+0x68/0x8c[ 52.047802] print_address_description.constprop.0+0x74/0x2c0[ 52.047809] kasan_report+0x210/0x230[ 52.047815] __asan_report_load1_noabort+0x3c/0x50[ 52.047820] snd_pcm_suspend_all+0x1a8/0x270[ 52.047824] snd_soc_suspend+0x19c/0x4e0The snd_pcm_sync_stop() has a NULL check on 'substream->runtime' beforemaking any access. So we need to always set 'substream->runtime' to NULLeverytime we kfree() it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46802 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: added NULL check at start of dc_validate_stream[Why]prevent invalid memory access[How]check if dc and stream are NULL

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46809 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check BIOS images before it is usedBIOS images may fail to load and null checks are added before they areused.This fixes 6 NULL_RETURNS issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46811 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix index may exceed array range within fpu_update_bw_bounding_box[Why]Coverity reports OVERRUN warning. soc.num_states couldbe 40. But array range of bw_params->clk_table.entries is 8.[How]Assert if soc.num_states greater than 8.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46822 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entryIn a review discussion of the changes to support vCPU hotplug wherea check was added on the GICC being enabled if was online, it wasnoted that there is need to map back to the cpu and use that to indexinto a cpumask. As such, a valid ID is needed.If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possiblefor the entry in cpu_madt_gicc[cpu] == NULL. This function wouldthen cause a NULL pointer dereference. Whilst a path to triggerthis has not been established, harden this caller against thepossibility.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46826 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ELF: fix kernel.randomize_va_space double readELF loader uses "randomize_va_space" twice. It is sysctl and can changeat any moment, so 2 loads could see 2 different values in theory withunpredictable consequences.Issue exactly one load for consistent value across one exec.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46828 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched: sch_cake: fix bulk flow accounting logic for host fairnessIn sch_cake, we keep track of the count of active bulk flows per host,when running in dst/src host fairness mode, which is used as theround-robin weight when iterating through flows. The count of activebulk flows is updated whenever a flow changes state.This has a peculiar interaction with the hash collision handling: when ahash collision occurs (after the set-associative hashing), the state ofthe hash bucket is simply updated to match the new packet that collided,and if host fairness is enabled, that also means assigning new per-hoststate to the flow. For this reason, the bulk flow counters of thehost(s) assigned to the flow are decremented, before new state isassigned (and the counters, which may not belong to the same hostanymore, are incremented again).Back when this code was introduced, the host fairness mode was alwaysenabled, so the decrement was unconditional. When the configurationflags were introduced the *increment* was made conditional, butthe *decrement* was not. Which of course can lead to a spuriousdecrement (and associated wrap-around to U16_MAX).AFAICT, when host fairness is disabled, the decrement and wrap-aroundhappens as soon as a hash collision occurs (which is not that common initself, due to the set-associative hashing). However, in most cases thisis harmless, as the value is only used when host fairness mode isenabled. So in order to trigger an array overflow, sch_cake has to firstbe configured with host fairness disabled, and while running in thismode, a hash collision has to occur to cause the overflow. Then, theqdisc has to be reconfigured to enable host fairness, which leads to thearray out-of-bounds because the wrapped-around value is retained andused as an array index. It seems that syzbot managed to trigger this,which is quite impressive in its own right.This patch fixes the issue by introducing the same conditional check ondecrement as is used on increment.The original bug predates the upstreaming of cake, but the commit listedin the Fixes tag touched that code, meaning that this patch won't applybefore that.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46840 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: clean up our handling of refs == 0 in snapshot deleteIn reada we BUG_ON(refs == 0), which could be unkind since we aren'tholding a lock on the extent leaf and thus could get a transientincorrect answer. In walk_down_proc we also BUG_ON(refs == 0), whichcould happen if we have extent tree corruption. Change that to return-EUCLEAN. In do_walk_down() we catch this case and handle it correctly,however we return -EIO, which -EUCLEAN is a more appropriate error code.Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convertthat to proper error handling. Also adjust the error message so we canactually do something with the information.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46841 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()We handle errors here properly, ENOMEM isn't fatal, return the error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46842 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_infoThe MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and theroutine unconditionally frees submitted mailbox commands regardless ofreturn status. The issue is that for MBX_TIMEOUT cases, when firmwarereturns SFP information at a later time, that same mailbox memory regionreferences previously freed memory in its cmpl routine.Fix by adding checks for the MBX_TIMEOUT return code. During mailboxresource cleanup, check the mbox flag to make sure that the wait did nottimeout. If the MBOX_WAKE flag is not set, then do not free the resourcesbecause it will be freed when firmware completes the mailbox at a latertime in its cmpl routine.Also, increase the timeout from 30 to 60 seconds to accommodate bootscripts requiring longer timeouts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46848 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel: Limit the period on HaswellRunning the ltp test cve-2015-3290 concurrently reports the followingwarnings.perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330Thanks to Thomas Gleixner's analysis, the issue is caused by the lowinitial period (1) of the frequency estimation algorithm, which triggersthe defects of the HW, specifically erratum HSW11 and HSW143. (For thedetails, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)The HSW11 requires a period larger than 100 for the INST_RETIRED.ALLevent, but the initial period in the freq mode is 1. The erratum is thesame as the BDM11, which has been supported in the kernel. A minimumperiod of 128 is enforced as well on HSW.HSW143 is regarding that the fixed counter 1 may overcount 32 with theHyper-Threading is enabled. However, based on the test, the hardwarehas more issues than it tells. Besides the fixed counter 1, the message'interrupt took too long' can be observed on any counter which was armedwith a period < 32 and two events expired in the same NMI. A minimumperiod of 32 is enforced for the rest of the events.The recommended workaround code of the HSW143 is not implemented.Because it only addresses the issue for the fixed counter. It bringsextra overhead through extra MSR writing. No related overcounting issuehas been reported so far.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf: heaps: Fix off-by-one in CMA heap fault handlerUntil VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps:Don't track CMA dma-buf pages under RssFile") it was possible to obtaina mapping larger than the buffer size via mremap and bypass the overflowcheck in dma_buf_mmap_internal. When using such a mapping to attempt tofault past the end of the buffer, the CMA heap fault handler also checksthe fault offset against the buffer size, but gets the boundary wrong by1. Fix the boundary check so that we don't read off the end of the pagesarray and insert an arbitrary page in the mapping.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: nxp-fspi: fix the KASAN report out-of-bounds bugChange the memcpy length to fix the out-of-bounds issue when writing thedata that is not 4 byte aligned to TX FIFO.To reproduce the issue, write 3 bytes data to NOR chip.dd if=3b of=/dev/mtd0[ 36.926103] ==================================================================[ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838[ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455[ 36.946721][ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070[ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT)[ 36.961260] Call trace:[ 36.963723] dump_backtrace+0x90/0xe8[ 36.967414] show_stack+0x18/0x24[ 36.970749] dump_stack_lvl+0x78/0x90[ 36.974451] print_report+0x114/0x5cc[ 36.978151] kasan_report+0xa4/0xf0[ 36.981670] __asan_report_load_n_noabort+0x1c/0x28[ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838[ 36.990800] spi_mem_exec_op+0x8ec/0xd30[ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0[ 36.999323] spi_mem_dirmap_write+0x238/0x32c[ 37.003710] spi_nor_write_data+0x220/0x374[ 37.007932] spi_nor_write+0x110/0x2e8[ 37.011711] mtd_write_oob_std+0x154/0x1f0[ 37.015838] mtd_write_oob+0x104/0x1d0[ 37.019617] mtd_write+0xb8/0x12c[ 37.022953] mtdchar_write+0x224/0x47c[ 37.026732] vfs_write+0x1e4/0x8c8[ 37.030163] ksys_write+0xec/0x1d0[ 37.033586] __arm64_sys_write+0x6c/0x9c[ 37.037539] invoke_syscall+0x6c/0x258[ 37.041327] el0_svc_common.constprop.0+0x160/0x22c[ 37.046244] do_el0_svc+0x44/0x5c[ 37.049589] el0_svc+0x38/0x78[ 37.052681] el0t_64_sync_handler+0x13c/0x158[ 37.057077] el0t_64_sync+0x190/0x194[ 37.060775][ 37.062274] Allocated by task 455:[ 37.065701] kasan_save_stack+0x2c/0x54[ 37.069570] kasan_save_track+0x20/0x3c[ 37.073438] kasan_save_alloc_info+0x40/0x54[ 37.077736] __kasan_kmalloc+0xa0/0xb8[ 37.081515] __kmalloc_noprof+0x158/0x2f8[ 37.085563] mtd_kmalloc_up_to+0x120/0x154[ 37.089690] mtdchar_write+0x130/0x47c[ 37.093469] vfs_write+0x1e4/0x8c8[ 37.096901] ksys_write+0xec/0x1d0[ 37.100332] __arm64_sys_write+0x6c/0x9c[ 37.104287] invoke_syscall+0x6c/0x258[ 37.108064] el0_svc_common.constprop.0+0x160/0x22c[ 37.112972] do_el0_svc+0x44/0x5c[ 37.116319] el0_svc+0x38/0x78[ 37.119401] el0t_64_sync_handler+0x13c/0x158[ 37.123788] el0t_64_sync+0x190/0x194[ 37.127474][ 37.128977] The buggy address belongs to the object at ffff00081037c2a0[ 37.128977] which belongs to the cache kmalloc-8 of size 8[ 37.141177] The buggy address is located 0 bytes inside of[ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)[ 37.153465][ 37.154971] The buggy address belongs to the physical page:[ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c[ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)[ 37.175149] page_type: 0xfdffffff(slab)[ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000[ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000[ 37.194553] page dumped because: kasan: bad access detected[ 37.200144][ 37.201647] Memory state around the buggy address:[ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc[ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc[ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc[ 37.228186] ^[ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 37.246962] ==============================================================---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_socket: fix sk refcount leaksWe must put 'sk' reference before returning.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix bridge mode operations when there are no VFsCurrently, trying to set the bridge mode attribute when numvfs=0 leads to acrash:bridge link set dev eth2 hwmode vepa[ 168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030[...][ 168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core][...][ 168.976037] Call Trace:[ 168.976188] [ 168.978620] _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core][ 168.979074] mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core][ 168.979471] rtnl_bridge_setlink+0xe9/0x1f0[ 168.979714] rtnetlink_rcv_msg+0x159/0x400[ 168.980451] netlink_rcv_skb+0x54/0x100[ 168.980675] netlink_unicast+0x241/0x360[ 168.980918] netlink_sendmsg+0x1f6/0x430[ 168.981162] ____sys_sendmsg+0x3bb/0x3f0[ 168.982155] ___sys_sendmsg+0x88/0xd0[ 168.985036] __sys_sendmsg+0x59/0xa0[ 168.985477] do_syscall_64+0x79/0x150[ 168.987273] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 168.987773] RIP: 0033:0x7f8f7950f917(esw->fdb_table.legacy.vepa_fdb is null)The bridge mode is only relevant when there are multiple functions perport. Therefore, prevent setting and getting this setting when there are noVFs.Note that after this change, there are no settings to change on the PFinterface using `bridge link` when there are no VFs, so the interface nolonger appears in the `bridge link` output.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46858 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: Fix uaf in __timer_delete_syncThere are two paths to access mptcp_pm_del_add_timer, result in a racecondition: CPU1 CPU2 ==== ==== net_rx_action napi_poll netlink_sendmsg __napi_poll netlink_unicast process_backlog netlink_unicast_kernel __netif_receive_skb genl_rcv __netif_receive_skb_one_core netlink_rcv_skb NF_HOOK genl_rcv_msg ip_local_deliver_finish genl_family_rcv_msg ip_protocol_deliver_rcu genl_family_rcv_msg_doit tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit tcp_v4_do_rcv mptcp_nl_remove_addrs_list tcp_rcv_established mptcp_pm_remove_addrs_and_subflows tcp_data_queue remove_anno_list_by_saddr mptcp_incoming_options mptcp_pm_del_add_timer mptcp_pm_del_add_timer kfree(entry)In remove_anno_list_by_saddr(running on CPU2), after leaving the criticalzone protected by "pm.lock", the entry will be released, which leads to theoccurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).Keeping a reference to add_timer inside the lock, and callingsk_stop_timer_sync() with this reference, instead of "entry->add_timer".Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock,do not directly access any members of the entry outside the pm lock, whichcan avoid similar "entry->x" uaf.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-46859 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: panasonic-laptop: Fix SINF array out of bounds accessesThe panasonic laptop code in various places uses the SINF array with indexvalues of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF arrayis big enough.Not all panasonic laptops have this many SINF array entries, for examplethe Toughbook CF-18 model only has 10 SINF array entries. So it onlysupports the AC+DC brightness entries and mute.Check that the SINF array has a minimum size which covers all AC+DCbrightness entries and refuse to load if the SINF array is smaller.For higher SINF indexes hide the sysfs attributes when the SINF arraydoes not contain an entry for that attribute, avoiding show()/store()accessing the array out of bounds and add bounds checking to the probe()and resume() code accessing these.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47658 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: stm32/cryp - call finalize with bh disabledThe finalize operation in interrupt mode produce a produces a spinlockrecursion warning. The reason is the fact that BH must be disabledduring this process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47666 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Set phy->enable_completion only when we wait for itpm8001_phy_control() populates the enable_completion pointer with a stackaddress, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, andreturns. The problem arises when a phy control response comes late. After300 ms the pm8001_phy_control() function returns and the passedenable_completion stack address is no longer valid. Late phy controlresponse invokes complete() on a dangling enable_completion pointer whichleads to a kernel crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47670 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: add bounds checking to ocfs2_xattr_find_entry()Add a paranoia check to make sure it doesn't stray beyond valid memoryregion containing ocfs2 xattr entries when scanning for a match. It willprevent out-of-bound access in case of crafted images.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47678 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:icmp: change the order of rate limitsICMP messages are ratelimited :After the blamed commits, the two rate limiters are applied in this order:1) host wide ratelimit (icmp_global_allow())2) Per destination ratelimit (inetpeer based)In order to avoid side-channels attacks, we need to applythe per destination check first.This patch makes the following change :1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3)2) The per destination limit is checked/updated. This might add a new node in inetpeer tree.3) icmp_global_consume() consumes tokens if prior operations succeeded.This means that host wide ratelimit is still effectivein keeping inetpeer tree small even under DDOS.As a bonus, I removed icmp_global.lock as the fast pathcan use a lock-free operation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47692 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: return -EINVAL when namelen is 0When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it mayresult in namelen being 0, which will cause memdup_user() to returnZERO_SIZE_PTR.When we access the name.data that has been assigned the value ofZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference istriggered.[ T1205] ==================================================================[ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260[ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205[ T1205][ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406[ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014[ T1205] Call Trace:[ T1205] dump_stack+0x9a/0xd0[ T1205] ? nfs4_client_to_reclaim+0xe9/0x260[ T1205] __kasan_report.cold+0x34/0x84[ T1205] ? nfs4_client_to_reclaim+0xe9/0x260[ T1205] kasan_report+0x3a/0x50[ T1205] nfs4_client_to_reclaim+0xe9/0x260[ T1205] ? nfsd4_release_lockowner+0x410/0x410[ T1205] cld_pipe_downcall+0x5ca/0x760[ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0[ T1205] ? down_write_killable_nested+0x170/0x170[ T1205] ? avc_policy_seqno+0x28/0x40[ T1205] ? selinux_file_permission+0x1b4/0x1e0[ T1205] rpc_pipe_write+0x84/0xb0[ T1205] vfs_write+0x143/0x520[ T1205] ksys_write+0xc9/0x170[ T1205] ? __ia32_sys_read+0x50/0x50[ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110[ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110[ T1205] do_syscall_64+0x33/0x40[ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1[ T1205] RIP: 0033:0x7fdbdb761bc7[ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514[ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001[ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7[ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008[ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001[ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b[ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000[ T1205] ==================================================================Fix it by checking namelen.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47705 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: fix potential invalid pointer dereference in blk_add_partitionThe blk_add_partition() function initially used a single if-condition(IS_ERR(part)) to check for errors when adding a partition. This wasmodified to handle the specific case of -ENXIO separately, allowing thefunction to proceed without logging the error in this case. However,this change unintentionally left a path where md_autodetect_dev()could be called without confirming that part is a valid pointer.This commit separates the error handling logic by splitting theinitial if-condition, improving code readability and handling specificerror scenarios explicitly. The function now distinguishes the generalerror case from -ENXIO without altering the existing behavior ofmd_autodetect_dev() calls.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47707 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()Blamed commit accidentally removed a check for rt->rt6i_idev being NULL,as spotted by syzbot:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06RSP: 0018:ffffc900047374e0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8cR10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 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/0x7fRIP: 0033:0x7f1acc77def9Code: Unable to access opcode bytes at 0x7f1acc77decf.RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in:---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06RSP: 0018:ffffc900047374e0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0R---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47713 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()Since '__dev_queue_xmit()' should be called with interrupts enabled,the following backtrace:ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() netlink_broadcast_filtered() do_one_broadcast() netlink_broadcast_deliver() __netlink_sendskb() netlink_deliver_tap() __netlink_deliver_tap_skb() dev_queue_xmit() __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags)issues the warning (as reported by syzbot reproducer):WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120Fix this by implementing a two-phase skb reclamation in'ieee80211_do_stop()', where actual work is performedoutside of a section with interrupts disabled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47730 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/qm - inject error before stopping queueThe master ooo cannot be completely closed when theaccelerator core reports memory error. Therefore, the driverneeds to inject the qm error to close the master ooo. Currently,the qm error is injected after stopping queue, memory may bereleased immediately after stopping queue, causing the device toaccess the released memory. Therefore, error is injected to close masterooo before stopping queue to ensure that the device does not accessthe released memory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47735 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabledFix missuse of spin_lock_irq()/spin_unlock_irq() whenspin_lock_irqsave()/spin_lock_irqrestore() was hold.This was discovered through the lock debugging, and the correspondinglog is as follows:raw_local_irq_restore() called with IRQs enabledWARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40...Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47736 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: handle overlapped pclusters out of crafted images properlysyzbot reported a task hang issue due to a deadlock case where it iswaiting for the folio lock of a cached folio that will be used forcache I/Os.After looking into the crafted fuzzed image, I found it's formed withseveral overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384...Here, extent 0/1 are physically overlapped although it's entirely_impossible_ for normal filesystem images generated by mkfs.First, managed folios containing compressed data will be marked asup-to-date and then unlocked immediately (unlike in-place folios) whencompressed I/Os are complete. If physical blocks are not submitted inthe incremental order, there should be separate BIOs to avoid dependencyissues. However, the current code mis-arranges z_erofs_fill_bio_vec()and BIO submission which causes unexpected BIO waits.Second, managed folios will be connected to their own pclusters forefficient inter-queries. However, this is somewhat hard to implementeasily if overlapped big pclusters exist. Again, these only appear infuzzed images so let's simply fall back to temporary short-lived pagesfor correctness.Additionally, it justifies that referenced managed folios cannot betruncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidyup `struct z_erofs_bvec`") for simplicity although it shouldn't be anydifference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47738 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: don't use rate mask for offchannel TX eitherLike the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask forscanning"), ignore incorrect settings to avoid no supported rate warningreported by syzbot.The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211:fix default HE tx bitrate mask in 2G band"), which however correctsbitmask of HE MCS and recognizes correctly settings of empty legacy rateplus HE MCS rate instead of returning -EINVAL.As suggestions [1], follow the change of SCAN TX to consider this case ofoffchannel TX as well.[1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47739 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:padata: use integer wrap around to prevent deadlock on seq_nr overflowWhen submitting more than 2^32 padata objects to padata_do_serial, thecurrent sorting implementation incorrectly sorts padata objects withoverflowed seq_nr, causing them to be placed before existing objects inthe reorder list. This leads to a deadlock in the serialization processas padata_find_next cannot match padata->seq_nr and pd->processedbecause the padata instance with overflowed seq_nr will be selectednext.To fix this, we use an unsigned integer wrap around to correctly sortpadata objects in scenarios with integer overflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47749 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cxgb4: Added NULL check for lookup_atidThe lookup_atid() function can return NULL if the ATID isinvalid or does not exist in the identifier table, whichcould lead to dereferencing a null pointer without acheck in the `act_establish()` and `act_open_rpl()` functions.Add a NULL check to prevent null pointer dereferencing.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-47809 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dlm: fix possible lkb_resource null dereferenceThis patch fixes a possible null pointer dereference when this function iscalled from request_lock() as lkb->lkb_resource is not assigned yet,only after validate_lock_args() by calling attach_lkb(). Another issueis that a resource name could be a non printable bytearray and we cannotassume to be ASCII coded.The log functionality is probably never being hit when DLM is used innormal way and no debug logging is enabled. The null pointer dereferencecan only occur on a new created lkb that does not have the resourceassigned yet, it probably never hits the null pointer dereference but weshould be sure that other changes might not change this behaviour and weactually can hit the mentioned null pointer dereference.In this patch we just drop the printout of the resource name, the lkb idis enough to make a possible connection to a resource name if thisexists.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-48881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bcache: revert replacing IS_ERR_OR_NULL with IS_ERR againCommit 028ddcac477b ("bcache: Remove unnecessary NULL point check innode allocations") leads a NULL pointer deference in cache_set_flush().1721 if (!IS_ERR_OR_NULL(c->root))1722 list_add(&c->root->list, &c->btree_cache);>From the above code in cache_set_flush(), if previous registration codefails before allocating c->root, it is possible c->root is NULL as whatit is initialized. __bch_btree_node_alloc() never returns NULL butc->root is possible to be NULL at above line 1721.This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49851 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Clean up TPM space after command failuretpm_dev_transmit prepares the TPM space before attempting commandtransmission. However if the command fails no rollback of thispreparation is done. This can result in transient handles being leakedif the device is subsequently closed with no further commands performed.Fix this by flushing the space in the event of command transmissionfailure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()The kref_put() function will call nport->release if the refcount drops tozero. The nport->release release function is _efc_nport_free() which frees"nport". But then we dereference "nport" on the next line which is a useafter free. Re-order these lines to avoid the use after free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling codefrom control queue handler") a null pointer dereference bug can betriggered when guest sends an SCSI AN request.In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with`&v_req.tmf.lun[1]` within a switch-case block and is then passed tovhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, fora `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` isset to NULL in this branch. Later, in vhost_scsi_get_req(),`vc->target` is dereferenced without being checked, leading to a nullpointer dereference bug. This bug can be triggered from guest.When this bug occurs, the vhost_worker process is killed while holding`vq->mutex` and the corresponding tpg will remain occupiedindefinitely.Below is the KASAN report:Oops: general protection fault, probably for non-canonical address0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:vhost_scsi_get_req+0x165/0x3a0Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 0048 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b604 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00RSP: 0018:ffff888017affb50 EFLAGS: 00010246RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350... ---[ end trace 0000000000000000 ]---Let's add a check in vhost_scsi_get_req.[whitespace fixes]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: update orig_path in ext4_find_extent()In ext4_find_extent(), if the path is not big enough, we free it and set*orig_path to NULL. But after reallocating and successfully initializingthe path, we don't update *orig_path, in which case the caller gets avalid path but a NULL ppath, and this may cause a NULL pointer dereferenceor a path memory leak. For example:ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference!==================================================================BUG: kernel NULL pointer dereference, address: 0000000000000010CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847RIP: 0010:ext4_split_extent_at+0x6d/0x560Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0[...]==================================================================Therefore, *orig_path is updated when the extent lookup succeeds, so thatthe caller can safely use path or *ppath.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49882 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix double brelse() the buffer of the extents pathIn ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has beenreleased, otherwise it may be released twice. An example of what triggersthis is as follows: split2 map split1|--------|-------|--------|ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twiceFinally got the following WARRNING when removing the buffer from lru:============================================VFS: brelse: Trying to free free bufferWARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716RIP: 0010:__brelse+0x58/0x90Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70[...]============================================

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49883 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: aovid use-after-free in ext4_ext_insert_extent()As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path isreallocated in ext4_ext_create_new_leaf(), we'll use the stale path andcause UAF. Below is a sample trace with dummy values:ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr==================================================================BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800[...]Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700[...]Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700[...]==================================================================So use *ppath to update the path to avoid the above problem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49886 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bugAttaching SST PCI device to VM causes "BUG: KASAN: slab-out-of-bounds".kasan report:[ 19.411889] ==================================================================[ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113[ 19.417368][ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10[ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022[ 19.422687] Call Trace:[ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80[ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.428694] print_report+0x19d/0x52e[ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10[ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.433539] kasan_report+0xf0/0x170[ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10[ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common][ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common][ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360[ 19.444797] cpuhp_invoke_callback+0x221/0xec0[ 19.446337] cpuhp_thread_fun+0x21b/0x610[ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10[ 19.449354] smpboot_thread_fn+0x2e7/0x6e0[ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10[ 19.452405] kthread+0x29c/0x350[ 19.453817] ? __pfx_kthread+0x10/0x10[ 19.455253] ret_from_fork+0x31/0x70[ 19.456685] ? __pfx_kthread+0x10/0x10[ 19.458114] ret_from_fork_asm+0x1a/0x30[ 19.459573] [ 19.460853][ 19.462055] Allocated by task 1198:[ 19.463410] kasan_save_stack+0x30/0x50[ 19.464788] kasan_save_track+0x14/0x30[ 19.466139] __kasan_kmalloc+0xaa/0xb0[ 19.467465] __kmalloc+0x1cd/0x470[ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common][ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr][ 19.471670] do_one_initcall+0xa4/0x380[ 19.472903] do_init_module+0x238/0x760[ 19.474105] load_module+0x5239/0x6f00[ 19.475285] init_module_from_file+0xd1/0x130[ 19.476506] idempotent_init_module+0x23b/0x650[ 19.477725] __x64_sys_finit_module+0xbe/0x130[ 19.476506] idempotent_init_module+0x23b/0x650[ 19.477725] __x64_sys_finit_module+0xbe/0x130[ 19.478920] do_syscall_64+0x82/0x160[ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 19.481292][ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512[ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200)[ 19.487447][ 19.488328] The buggy address belongs to the physical page:[ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60[ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0[ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff)[ 19.493914] page_type: 0xffffffff()[ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001[ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000[ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001[ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000[ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff[ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000[ 19.503784] page dumped because: k---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49890 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: ensure the fw_info is not null before using itThis resolves the dereference null return value warningreported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49891 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata pathsWhen the HBA is undergoing a reset or is handling an errata event, NULL ptrdereference crashes may occur in routines such aslpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), orlpfc_abort_handler().Add NULL ptr checks before dereferencing hdwq pointers that may have beenfreed due to operations colliding with a reset or errata event handler.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49892 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Initialize get_bytes_per_element's default to 1Variables, used as denominators and maybe not assigned to other values,should not be 0. bytes_per_element_y & bytes_per_element_c areinitialized by get_bytes_per_element() which should never return 0.This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49896 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check stream before comparing them[WHAT & HOW]amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It isnecessary to check for null before dereferencing them.This fixes 1 FORWARD_NULL issue reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Initialize denominators' default to 1[WHAT & HOW]Variables used as denominators and maybe not assigned to other values,should not be 0. Change their default to 1 so they are never 0.This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49901 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrsThere are some cases, such as the one uncovered by Commit 46d4efcccc68("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails")wheremsm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL);is called on gpu->pdev == NULL, as the GPU device has not been fullyinitialized yet.Turns out that there's more than just the aforementioned path thatcauses this to happen (e.g. the case when there's speedbin data in thecatalog, but opp-supported-hw is missing in DT).Assigning msm_gpu->pdev earlier seems like the least painful solutionto this, therefore do so.Patchwork: https://patchwork.freedesktop.org/patch/602742/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49905 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2)This commit adds a null check for the 'afb' variable in theamdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' wasassumed to be null, but was used later in the code without a null check.This could potentially lead to a null pointer dereference.Changes since v1:- Moved the null check for 'afb' to the line where 'afb' is used. (Alex)Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49907 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointers before using dc->clk_mgr[WHY & HOW]dc->clk_mgr is null checked previously in the same function, indicatingit might be null.Passing "dc" to "dc->hwss.apply_idle_power_optimizations", whichdereferences null "dc->clk_mgr". (The function pointer resolves to"dcn35_apply_idle_power_optimizations".)This fixes 1 FORWARD_NULL issue reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49911 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_funcThis commit adds a null check for the set_output_gamma function pointerin the dcn20_set_output_transfer_func function. Previously,set_output_gamma was being checked for null at line 1030, but then itwas being dereferenced without any null check at line 1048. This couldpotentially lead to a null pointer dereference error if set_output_gammais null.To fix this, we now ensure that set_output_gamma is not null beforedereferencing it. We do this by adding a null check for set_output_gammabefore the call to set_output_gamma at line 1048.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49913 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_streamThis commit addresses a null pointer dereference issue in the`commit_planes_for_stream` function at line 4140. The issue could occurwhen `top_pipe_to_program` is null.The fix adds a check to ensure `top_pipe_to_program` is not null beforeaccessing its stream_res. This prevents a null pointer dereference.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49914 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue in the`dcn20_program_pipe` function. The issue could occur when`pipe_ctx->plane_state` is null.The fix adds a check to ensure `pipe_ctx->plane_state` is not nullbefore accessing. This prevents a null pointer dereference.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49917 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hwThis commit addresses a potential null pointer dereference issue in the`dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or`dc->clk_mgr->funcs` is null.The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` isnot null before accessing its functions. This prevents a potential nullpointer dereference.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49920 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointers before multiple uses[WHAT & HOW]Poniters, such as stream_enc and dc->bw_vbios, are null checked previouslyin the same function, so Coverity warns "implies that stream_enc anddc->bw_vbios might be null". They are used multiple times in thesubsequent code and need to be checked.This fixes 10 FORWARD_NULL issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49921 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointers before used[WHAT & HOW]Poniters, such as dc->clk_mgr, are null checked previously in the samefunction, so Coverity warns "implies that "dc->clk_mgr" might be null".As a result, these pointers need to be checked when used again.This fixes 10 FORWARD_NULL issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointers before using them[WHAT & HOW]These pointers are null checked previously in the same function,indicating they might be null as reported by Coverity. As a result,they need to be checked when used again.This fixes 3 FORWARD_NULL issue reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49923 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags[WHAT & HOW]"dcn20_validate_apply_pipe_split_flags" dereferences merge, and thus itcannot be a null pointer. Let's pass a valid pointer to avoid nulldereference.This fixes 2 FORWARD_NULL issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49929 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: avoid NULL pointer dereferenceiwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvstapointer is not NULL.It retrieves this pointer using iwl_mvm_sta_from_mac80211, which isdereferencing the ieee80211_sta pointer.If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULLpointer.Fix this by checking the sta pointer before retrieving the mvmstafrom it. If sta is not NULL, then mvmsta isn't either.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49935 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: PAD: fix crash in exit_round_robin()The kernel occasionally crashes in cpumask_clear_cpu(), which is calledwithin exit_round_robin(), because when executing clear_bit(nr, addr) withnr set to 0xffffffff, the address calculation may cause misalignment withinthe memory, leading to access to an invalid memory address.----------BUG: unable to handle kernel paging request at ffffffffe0740618 ...CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ...RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000eR13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000eFS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ...CR2: ffffffffe0740618crash> dis -lr ffffffffc0726923 .../usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 1140xffffffffc0726918 : mov %r12d,%r12d/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 3250xffffffffc072691b : mov -0x3f8d7de0(,%r12,4),%eax/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 800xffffffffc0726923 : lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14]$66 = 0xffffffffcrash> px 0xffffffffc072692c+0x19cf4$99 = 0xffffffffc0740620crash> sym 0xffffffffc0740620ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]crash> px pad_busy_cpus_bits[0]$42 = 0xfffc0----------To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before callingcpumask_clear_cpu() in exit_round_robin(), just as it is done inround_robin_cpu().[ rjw: Subject edit, avoid updates to the same value ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49939 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw89: avoid to add interface to list twice when SERIf SER L2 occurs during the WoWLAN resume flow, the add interface flowis triggered by ieee80211_reconfig(). However, due tortw89_wow_resume() return failure, it will cause the add interface flowto be executed again, resulting in a double add list and causing a kernelpanic. Therefore, we have added a check to prevent double adding of thelist.list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628.------------[ cut here ]------------kernel BUG at lib/list_debug.c:37!invalid opcode: 0000 [#1] PREEMPT SMP NOPTICPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021Workqueue: events_freezable ieee80211_restart_work [mac80211]RIP: 0010:__list_add_valid_or_report+0x5e/0xb0Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydevgsmi: Log Shutdown Reason 0x03---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49944 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_startIn sctp_listen_start() invoked by sctp_inet_listen(), it should set thesk_state back to CLOSED if sctp_autobind() fails due to whatever reason.Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuseis already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash willbe dereferenced as sk_state is LISTENING, which causes a crash as bind_hashis NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49946 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: do not assume bh is held in ppp_channel_bridge_input()Networking receive path is usually handled from BH handler.However, some protocols need to acquire the socket lock, andpackets might be stored in the socket backlog is the socket wasowned by a user process.In this case, release_sock(), __release_sock(), and sk_backlog_rcv()might call the sk->sk_backlog_rcv() handler in process context.sybot caught ppp was not considering this case inppp_channel_bridge_input() :WARNING: inconsistent lock state6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted--------------------------------inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304{SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK ***1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325stack backtrace:CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49948 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: add more sanity checks to qdisc_pkt_len_init()One path takes care of SKB_GSO_DODGY, assumingskb->len is bigger than hdr_len.virtio_net_hdr_to_skb() does not fully dissect TCP headers,it only make sure it is at least 20 bytes.It is possible for an user to provide a malicious 'GSO' packet,total length of 80 bytes.- 20 bytes of IPv4 header- 60 bytes TCP header- a small gso_size like 8virtio_net_hdr_to_skb() would declare this packet as a normalGSO packet, because it would see 40 bytes of payload,bigger than gso_size.We need to make detect this case to not underflowqdisc_skb_cb(skb)->pkt_len.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49949 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: avoid potential underflow in qdisc_pkt_len_init() with UFOAfter commit 7c6d2ecbda83 ("net: be more gentle about silly gsorequests coming from user") virtio_net_hdr_to_skb() had sanity checkto detect malicious attempts from user space to cook a bad GSO packet.Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: counttransport header in UFO") while fixing one issue, allowed user spaceto cook a GSO packet with the following characteristic :IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28.When this packet arrives in qdisc_pkt_len_init(), we end upwith hdr_len = 28 (IPv4 header + UDP header), matching skb->lenThen the following sets gso_segs to 0 :gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size);Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len;This leads to the following crash in fq_codel [1]qdisc_pkt_len_init() is best effort, we only want an estimationof the bytes sent on the wire, not crashing the kernel.This patch is fixing this particular issue, a following oneadds more sanity checks for another potential bug.[1][ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 70.724561] #PF: supervisor read access in kernel mode[ 70.724561] #PF: error_code(0x0000) - not-present page[ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0[ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI[ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991[ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49All code======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WBCode starting with the faulting instruction=========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB[ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202[ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000[ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001[ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000[ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58[ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000[ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000[ 70.724561] CS: 0010 DS: 0000 ES: 0000 C---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49952 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: prevent nf_skb_duplicated corruptionsyzbot found that nf_dup_ipv4() or nf_dup_ipv6() could writeper-cpu variable nf_skb_duplicated in an unsafe way [1].Disabling preemption as hinted by the splat is not enough,we have to disable soft interrupts as well.[1]BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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/0x7fRIP: 0033:0x7f4ce4f7def9Code: 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49954 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:static_call: Replace pointless WARN_ON() in static_call_module_notify()static_call_module_notify() triggers a WARN_ON(), when memory allocationfails in __static_call_add_module().That's not really justified, because the failure case must be correctlyhandled by the well known call chain and the error code is passedthrough to the initiating userspace application.A memory allocation fail is not a fatal problem, but the WARN_ON() takesthe machine out when panic_on_warn is set.Replace it with a pr_warn().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49955 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: battery: Fix possible crash when unregistering a battery hookWhen a battery hook returns an error when adding a new battery, thenthe battery hook is automatically unregistered.However the battery hook provider cannot know that, so it will latercall battery_hook_unregister() on the already unregistered batteryhook, resulting in a crash.Fix this by using the list head to mark already unregistered batteryhooks as already being unregistered so that they can be ignored bybattery_hook_unregister().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49957 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix null-ptr-deref when journal load failed.During the mounting process, if journal_reset() fails because of too shortjournal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() callsjbd2_journal_flush()->jbd2_cleanup_journal_tail()->__jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail()->lock_buffer(journal->j_sb_buffer), resulting in a null-pointerdereference error.To resolve this issue, we should check the JBD2_LOADED flag to ensure thejournal was properly loaded. Additionally, use journal instead ofosb->journal directly to simplify the code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49958 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: reserve space for inline xattr before attaching reflink treeOne of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting,the fsck -fn output showed the below corruption[EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,but fsck believes the largest valid value is 227. Clamp the next record value? nThe stat output from the debugfs.ocfs2 showed the following corruptionwhere the "Next Free Rec:" had overshot the "Count:" in the root metadatablock. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... .......The issue was in the reflink workfow while reserving space for inlinexattr. The problematic function is ocfs2_reflink_xattr_inline(). By thetime this function is called the reflink tree is already recreated at thedestination inode from the source inode. At this point, this functionreserves space for inline xattrs at the destination inode without evenchecking if there is space at the root metadata block. It simply reducesthe l_count from 243 to 227 thereby making space of 256 bytes for inlinexattr whereas the inode already has extents beyond this index (in thiscase up to 230), thereby causing corruption.The fix for this is to reserve space for inline metadata at the destinationinode before the reflink tree gets recreated. The customer has verified thefix.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49959 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns errorIn __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()to recover some journal space. But if an error occurs while executingjbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for freespace right away, we try other branches, and if j_committing_transactionis NULL (i.e., the tid is 0), we will get the following complain:============================================JBD2: I/O error when updating journal superblock for sdd-8.__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available__jbd2_log_wait_for_space: no way to get more journal space in sdd-8------------[ cut here ]------------WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0Modules linked in:CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70[...]============================================So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing toclean up at the moment, continue to try to reclaim free space in other ways.Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corruptwhen updating journal superblock fails") to make jbd2_cleanup_journal_tailreturn the correct error code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49962 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will causeNULL pointer dereference later.[ rjw: Subject and changelog edits ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49963 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mailbox: bcm2835: Fix timeout during suspend modeDuring noirq suspend phase the Raspberry Pi power driver suffer offirmware property timeouts. The reason is that the IRQ of the underlyingBCM2835 mailbox is disabled and rpi_firmware_property_list() will alwaysrun into a timeout [1].Since the VideoCore side isn't consider as a wakeup source, set theIRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabledduring suspend-resume cycle.[1]PM: late suspend of devices complete after 1.754 msecsWARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22cFirmware transaction 0x00028001 timeoutModules linked in:CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17Hardware name: BCM2835Call trace:unwind_backtrace from show_stack+0x18/0x1cshow_stack from dump_stack_lvl+0x34/0x44dump_stack_lvl from __warn+0x88/0xec__warn from warn_slowpath_fmt+0x7c/0xb0warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22crpi_firmware_property_list from rpi_firmware_property+0x68/0x8crpi_firmware_property from rpi_firmware_set_power+0x54/0xc0rpi_firmware_set_power from _genpd_power_off+0xe4/0x148_genpd_power_off from genpd_sync_power_off+0x7c/0x11cgenpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0genpd_finish_suspend from dpm_run_callback+0x78/0xd0dpm_run_callback from device_suspend_noirq+0xc0/0x238device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5acsuspend_devices_and_enter from pm_suspend+0x254/0x2e4pm_suspend from state_store+0xa8/0xd4state_store from kernfs_fop_write_iter+0x154/0x1a0kernfs_fop_write_iter from vfs_write+0x12c/0x184vfs_write from ksys_write+0x78/0xc0ksys_write from ret_fast_syscall+0x0/0x54Exception stack(0xcc93dfa8 to 0xcc93dff0)[...]PM: noirq suspend of devices complete after 3095.584 msecs

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49965 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: remove unreasonable unlock in ocfs2_read_blocksPatch series "Misc fixes for ocfs2_read_blocks", v5.This series contains 2 fixes for ocfs2_read_blocks(). The first patch fixthe issue reported by syzbot, which detects bad unlock balance inocfs2_read_blocks(). The second patch fixes an issue reported by HemingZhao when reviewing above fix.This patch (of 2):There was a lock release before exiting, so remove the unreasonable unlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49966 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: cancel dqi_sync_work before freeing oinfoocfs2_global_read_info() will initialize and schedule dqi_sync_work at theend, if error occurs after successfully reading global quota, it willtrigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16cThis reports that there is an active delayed work when freeing oinfo inerror handling, so cancel dqi_sync_work first. BTW, return status insteadof -1 when .read_file_info fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49967 Severity: Moderate CVSS3 score: 5.5

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

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49973 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:r8169: add tally counter fields added with RTL8125RTL8125 added fields to the tally counter, what may result in the chipdma'ing these new fields to unallocated memory. Therefore make surethat the allocated memory area is big enough to hold all of thetally counter values, even if we use only parts of it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49975 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:uprobes: fix kernel info leak via "[uprobes]" vmaxol_add_vma() maps the uninitialized page allocated by __create_xol_area()into userspace. On some architectures (x86) this memory is readable evenwithout VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ,although this doesn't really matter, debugger can read this memory anyway.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49978 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gso: fix udp gso fraglist segmentation after pull from frag_listDetect gso fraglist skbs with corrupted geometry (see below) andpass these to skb_segment instead of skb_segment_list, as the firstcan segment them correctly.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 these skbs, breaking these invariants.In extreme cases they pull all data into skb linear. For UDP, thiscauses a NULL ptr deref in __udpv4_gso_segment_list_csum atudp_hdr(seg->next)->dest.Detect invalid geometry due to pull, by checking head_skb size.Don't just drop, as this may blackhole a destination. Convert to beable to pass to regular skb_segment.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49983 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-freeWhen calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(),the 'ppath' is updated but it is the 'path' that is freed, thus potentiallytriggering a double-free in the following process:ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!!So drop the unnecessary ppath and use path directly to avoid this problem.And use ext4_find_extent() directly to update path, avoiding unnecessarymemory allocation and freeing. Also, propagate the error returned byext4_find_extent() instead of using strange error codes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49985 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resumeIn case there is any sort of clock controller attached to this I2C buscontroller, for example Versaclock or even an AIC32x4 I2C codec, thenan I2C transfer triggered from the clock controller clk_ops .preparecallback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.This is because the clock controller first grabs the prepare_lock mutexand then performs the prepare operation, including its I2C access. TheI2C access resumes this I2C bus controller via .runtime_resume callback,which calls clk_prepare_enable(), which attempts to grab the prepare_lockmutex again and deadlocks.Since the clock are already prepared since probe() and unprepared inremove(), use simple clk_enable()/clk_disable() calls to enable anddisable the clock on runtime suspend and resume, to avoid hitting theprepare_lock mutex.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49994 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: fix integer overflow in BLKSECDISCARDI independently rediscovered commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 block: fix overflow in blk_ioctl_discard()but for secure erase.Same problem: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r);will enter near infinite loop inside blkdev_issue_secure_erase(): a.out: attempt to access beyond end of device loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 callbacks suppressed

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-49996 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix buffer overflow when parsing NFS reparse pointsReparseDataLength is sum of the InodeType size and DataBuffer size.So to get DataBuffer size it is needed to subtract InodeType's size fromReparseDataLength.Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBufferat position after the end of the buffer because it does not subtractInodeType size from the length. Fix this problem and correctly subtractvariable len.Member InodeType is present only when reparse buffer is large enough. Checkfor ReparseDataLength before accessing InodeType to prevent another invalidmemory access.Major and minor rdev values are present also only when reparse buffer islarge enough. Check for reparse buffer size before calling reparse_mkdev().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50000 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()In mlx5e_tir_builder_alloc() kvzalloc() may return NULLwhich is dereferenced on the next line in a referenceto the modify field.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50001 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix error path in multi-packet WQE transmitRemove the erroneous unmap in case no DMA mapping was establishedThe multi-packet WQE transmit code attempts to obtain a DMA mapping forthe skb. This could fail, e.g. under memory pressure, when the IOMMUdriver just can't allocate more memory for page tables. While the codetries to handle this in the path below the err_unmap label it erroneouslyunmaps one entry from the sq's FIFO list of active mappings. Since thecurrent map attempt failed this unmap is removing some random DMA mappingthat might still be required. If the PCI function now presents that IOVA,the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCIfunction in error state.The erroneous behavior was seen in a stress-test environment that createdmemory pressure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:static_call: Handle module init failure correctly in static_call_del_module()Module insertion invokes static_call_add_module() to initialize the staticcalls in a module. static_call_add_module() invokes __static_call_init(),which allocates a struct static_call_mod to either encapsulate the built-instatic call sites of the associated key into it so further modules can beadded or to append the module to the module chain.If that allocation fails the function returns with an error code and themodule core invokes static_call_del_module() to clean up eventually addedstatic_call_mod entries.This works correctly, when all keys used by the module were converted overto a module chain before the failure. If not then static_call_del_module()causes a #GP as it blindly assumes that key::mods points to a valid structstatic_call_mod.The problem is that key::mods is not a individual struct member of structstatic_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; };key::sites is a pointer to the list of built-in usage sites of the staticcall. The type of the pointer is differentiated by bit 0. A mods pointerhas the bit clear, the sites pointer has the bit set.As static_call_del_module() blidly assumes that the pointer is a validstatic_call_mod type, it fails to check for this failure case anddereferences the pointer to the list of built-in call sites, which isobviously bogus.Cure it by checking whether the key has a sites or a mods pointer.If it's a sites pointer then the key is not to be touched. As the sites arewalked in the same order as in __static_call_init() the site walk can beterminated because all subsequent sites have not been touched by the initcode due to the error exit.If it was converted before the allocation fail, then the inner loop whichsearches for a module match will find nothing.A fail in the second allocation in __static_call_init() is harmless anddoes not require special treatment. The first allocation succeeded andconverted the key to a module chain. That first entry has mod::mod == NULLand mod::next == NULL, so the inner loop of static_call_del_module() willneither find a module match nor a module chain. The next site in the walkwas either already converted, but can't match the module, or it will exitthe outer loop because it has a static_call_site pointer and not astatic_call_mod pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix memory leak in exfat_load_bitmap()If the first directory entry in the root directory is not a bitmapdirectory entry, 'bh' will not be released and reassigned, whichwill cause a memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50014 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix access to uninitialised lock in fc replay pathThe following kernel trace can be triggered with fstest generic/629 whenexecuted against a filesystem with fast-commit feature enabled:INFO: trying to register non-static key.The code is fine but needs lockdep annotation, or maybeyou didn't initialize this object before use?turning off the locking correctness validator.CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180...In the replay path there's an attempt to lock sbi->s_bdev_wb_lock infunction ext4_check_bdev_write_error(). Unfortunately, at this point thisspinlock has not been initialized yet. Moving it's initialization to anearlier point in __ext4_fill_super() fixes this splat.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50015 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: dax: fix overflowing extents beyond inode size when partially writingThe dax_iomap_rw() does two things in each iteration: map written blocksand copy user data to blocks. If the process is killed by user(See signalhandling in dax_iomap_iter()), the copied data will be returned and addedon inode size, which means that the length of written extents may exceedthe inode size, then fsck will fail. An example is given as:dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2Mfsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix?Fix the problem by truncating extents if the written length is smallerthan expected.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50019 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kthread: unpark only parked kthreadCalling into kthread unparking unconditionally is mostly harmless whenthe kthread is already unparked. The wake up is then simply ignoredbecause the target is not in TASK_PARKED state.However if the kthread is per CPU, the wake up is preceded by a callto kthread_bind() which expects the task to be inactive and inTASK_PARKED state, which obviously isn't the case if it is unparked.As a result, calling kthread_stop() on an unparked per-cpu kthreadtriggers such a warning: WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 kthread_stop+0x17a/0x630 kernel/kthread.c:707 destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 ops_exit_list net/core/net_namespace.c:178 [inline] cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Fix this with skipping unecessary unparking while stopping a kthread.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50024 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix an unsafe loop on the listThe kernel may crash when deleting a genetlink family if there are stilllisteners for that family:Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace:__netlink_clear_multicast_users+0x74/0xc0genl_unregister_family+0xd4/0x2d0Change the unsafe loop on the list to a safe one, because inside theloop there is an element removal from this list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50028 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: core: Reference count the zone in thermal_zone_get_by_id()There are places in the thermal netlink code where nothing preventsthe thermal zone object from going away while being accessed after ithas been returned by thermal_zone_get_by_id().To address this, make thermal_zone_get_by_id() get a reference on thethermal zone device object to be returned with the help of get_device(),under thermal_list_lock, and adjust all of its callers to this changewith the help of the cleanup.h infrastructure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50033 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:slip: make slhc_remember() more robust against malicious packetssyzbot found that slhc_remember() was missing checks againstmalicious packets [1].slhc_remember() only checked the size of the packet was at least 20,which is not good enough.We need to make sure the packet includes the IPv4 and TCP headerthat are supposed to be carried.Add iph and th pointers to make the code more readable.[1]BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50036 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: do not delay dst_entries_add() in dst_release()dst_entries_add() uses per-cpu data that might be freed at netnsdismantle from ip6_route_net_exit() calling dst_entries_destroy()Before ip6_route_net_exit() can be called, we release allthe dsts associated with this netns, via calls to dst_release(),which waits an rcu grace period before calling dst_destroy()dst_entries_add() use in dst_destroy() is racy, becausedst_entries_destroy() could have been called already.Decrementing the number of dsts must happen sooner.Notes:1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this.2) There is also discussion about removing this count of dst, which might happen in future kernels.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50038 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xtables: avoid NFPROTO_UNSPEC where neededsyzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packetprocessing. As this is only useful to restrict locally terminatingTCP/UDP traffic, register this for ipv4 and ipv6 family only.Pablo points out that this is a general issue, direct users of theset/getsockopt interface can call into targets/matches that were onlyintended for use with ip(6)tables.Check all UNSPEC matches and targets for similar issues:- matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area.- targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE.Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, asthey are provided for use by ip(6)tables.The MARK target is also used by arptables, so register for NFPROTO_ARP too.While at it, bail out if connbytes fails to enable the correspondingconntrack family.This change passes the selftests in iptables.git.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50039 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: accept TCA_STAB only for root qdiscMost qdiscs maintain their backlog using qdisc_pkt_len(skb)on the assumption it is invariant between the enqueue()and dequeue() handlers.Unfortunately syzbot can crash a host rather easily usinga TBF + SFQ combination, with an STAB on SFQ [1]We can't support TCA_STAB on arbitrary level, this wouldrequire to maintain per-qdisc storage.[1][ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 88.798611] #PF: supervisor read access in kernel mode[ 88.799014] #PF: error_code(0x0000) - not-present page[ 88.799506] PGD 0 P4D 0[ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI[ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117[ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq[ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00All code======== 0: 0f b7 50 12 movzwl 0x12(%rax),%edx 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax b: 00 c: 48 89 d6 mov %rdx,%rsi f: 48 29 d0 sub %rdx,%rax 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx 19: 48 c1 e0 03 shl $0x3,%rax 1d: 48 01 c2 add %rax,%rdx 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx) 25: 7e c0 jle 0xffffffffffffffe7 27: 48 8b 3a mov (%rdx),%rdi 2a:* 4c 8b 07 mov (%rdi),%r8 <-- trapping instruction 2d: 4c 89 02 mov %r8,(%rdx) 30: 49 89 50 08 mov %rdx,0x8(%r8) 34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 3b: 00 3c: 48 rex.W 3d: c7 .byte 0xc7 3e: 07 (bad) ...Code starting with the faulting instruction=========================================== 0: 4c 8b 07 mov (%rdi),%r8 3: 4c 89 02 mov %r8,(%rdx) 6: 49 89 50 08 mov %rdx,0x8(%r8) a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 11: 00 12: 48 rex.W 13: c7 .byte 0xc7 14: 07 (bad) ...[ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206[ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800[ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000[ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f[ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140[ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac[ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000[ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0[ 88.808165] Call Trace:[ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)[ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715)[ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539)[ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)[ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq[ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq[ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50041 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix macvlan leak by synchronizing access to mac_filter_hashThis patch addresses a macvlan leak issue in the i40e driver caused byconcurrent access to vsi->mac_filter_hash. The leak occurs when multiplethreads attempt to modify the mac_filter_hash simultaneously, leading toinconsistent state and potential memory leaks.To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroingvf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock),ensuring atomic operations and preventing concurrent access.Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) ini40e_add_mac_filter() to help catch similar issues in the future.Reproduction steps:1. Spawn VFs and configure port vlan on them.2. Trigger concurrent macvlan operations (e.g., adding and deleting portvlan and/or mac filters).3. Observe the potential memory leak and inconsistent state in the mac_filter_hash.This synchronization ensures the integrity of the mac_filter_hash and preventsthe described leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50044 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_changerfcomm_sk_state_change attempts to use sock_lock so it must never becalled with it locked but rfcomm_sock_ioctl always attempt to lock itcausing the following trace:======================================================WARNING: possible circular locking dependency detected6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted------------------------------------------------------syz-executor386/5093 is trying to acquire lock:ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73but task is already holding lock:ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50045 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: br_netfilter: fix panic with metadata_dst skbFix a kernel panic in the br_netfilter module when sending untaggedtraffic via a VxLAN device.This happens during the check for fragmentation in br_nf_dev_queue_xmit.It is dependent on:1) the br_netfilter module being loaded;2) net.bridge.bridge-nf-call-iptables set to 1;3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;4) untagged frames with size higher than the VxLAN MTU forwarded/floodedWhen forwarding the untagged packet to the VxLAN bridge port, beforethe netfilter hooks are called, br_handle_egress_vlan_tunnel is called andchanges the skb_dst to the tunnel dst. The tunnel_dst is a metadata typeof dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL.Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a checkfor frames that needs to be fragmented: frames with higher MTU than theVxLAN device end up calling br_nf_ip_fragment, which in turns callip_skb_dst_mtu.The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dstwith valid dst->dev, thus the crash.This case was never supported in the first place, so drop the packetinstead.PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.[ 176.291791] Unable to handle kernel NULL pointer dereference atvirtual address 0000000000000110[ 176.292101] Mem abort info:[ 176.292184] ESR = 0x0000000096000004[ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits[ 176.292530] SET = 0, FnV = 0[ 176.292709] EA = 0, S1PTW = 0[ 176.292862] FSC = 0x04: level 0 translation fault[ 176.293013] Data abort info:[ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000[ 176.294166] [0000000000000110] pgd=0000000000000000,p4d=0000000000000000[ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel vethbr_netfilter bridge stp llc ipv6 crct10dif_ce[ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted6.8.0-rc3-g5b3fbd61b9d1 #2[ 176.296314] Hardware name: linux,dummy-virt (DT)[ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBSBTYPE=--)[ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter][ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter][ 176.297636] sp : ffff800080003630[ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:ffff6828c49ad9f8[ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:00000000000003e8[ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:ffff6828c3b16d28[ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:0000000000000014[ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:0000000095744632[ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:ffffb7e137926a70[ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :0000000000000000[ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :f20e0100bebafeca[ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :0000000000000000[ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :ffff6828c7f918f0[ 176.300889] Call trace:[ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter][ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter][ 176.301703] nf_hook_slow+0x48/0x124[ 176.302060] br_forward_finish+0xc8/0xe8 [bridge][ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter][ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter][ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter][ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter][ 176.303359] nf_hook_slow+0x48/0x124[ 176.303---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50046 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()On the node of an NFS client, some files saved in the mountpoint of theNFS server were copied to another location of the same NFS server.Accidentally, the nfs42_complete_copies() got a NULL-pointer dereferencecrash with the following syslog:[232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116[232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116[232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058[232066.588586] Mem abort info:[232066.588701] ESR = 0x0000000096000007[232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits[232066.589084] SET = 0, FnV = 0[232066.589216] EA = 0, S1PTW = 0[232066.589340] FSC = 0x07: level 3 translation fault[232066.589559] Data abort info:[232066.589683] ISV = 0, ISS = 0x00000007[232066.589842] CM = 0, WnR = 0[232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400[232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000[232066.590757] Internal error: Oops: 96000007 [#1] SMP[232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2[232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs[232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1[232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06[232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4][232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4][232066.598595] sp : ffff8000f568fc70[232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000[232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001[232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050[232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000[232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000[232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6[232066.600498] x11: 00000000000000---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50049 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointer before dereferencing se[WHAT & HOW]se is null checked previously in the same function, indicatingit might be null; therefore, it must be checked when used again.This fixes 1 FORWARD_NULL issue reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50055 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:driver core: bus: Fix double free in driver API bus_register()For bus_register(), any error which happens after kset_register() willcause that @priv are freed twice, fixed by setting @priv with NULL afterthe first free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50058 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: protect uart_port_dtr_rts() in uart_shutdown() tooCommit af224ca2df29 (serial: core: Prevent unsafe uart port access, part3) added few uport == NULL checks. It added one to uart_shutdown(), sothe commit assumes, uport can be NULL in there. But right after thatprotection, there is an unprotected "uart_port_dtr_rts(uport, false);"call. That is invoked only if HUPCL is set, so I assume that is thereason why we do not see lots of these reports.Or it cannot be NULL at this point at all for some reason :P.Until the above is investigated, stay on the safe side and move thisdereference to the if too.I got this inconsistency from Coverity under CID 1585130. Thanks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50061 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race ConditionIn the cdns_i3c_master_probe function, &master->hj_work is bound withcdns_i3c_master_hj. And cdns_i3c_master_interrupt can callcnds_i3c_master_demux_ibis function to start the work.If we remove the module which will call cdns_i3c_master_remove tomake cleanup, it will free master->base through i3c_master_unregisterwhile the work mentioned above will be used. The sequence of operationsthat may lead to a UAF bug is as follows:CPU0 CPU1 | cdns_i3c_master_hjcdns_i3c_master_remove |i3c_master_unregister(&master->base) |device_unregister(&master->dev) |device_release |//free master->base | | i3c_master_do_daa(&master->base) | //use master->baseFix it by ensuring that the work is canceled before proceeding withthe cleanup in cdns_i3c_master_remove.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50062 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rtrs-srv: Avoid null pointer deref during path establishmentFor RTRS path establishment, RTRS client initiates and completes con_numof connections. After establishing all its connections, the informationis exchanged between the client and server through the info_req message.During this exchange, it is essential that all connections have beenestablished, and the state of the RTRS srv path is CONNECTED.So add these sanity checks, to make sure we detect and abort process inerror scenarios to avoid null pointer deref.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50067 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:uprobe: avoid out-of-bounds memory access of fetching argsUprobe needs to fetch args into a percpu buffer, and then copy to ringbuffer to avoid non-atomic context problem.Sometimes user-space strings, arrays can be very large, but the size ofpercpu buffer is only page size. And store_trace_args() won't checkwhether these data exceeds a single page or not, caused out-of-boundsmemory access.It could be reproduced by following steps:1. build kernel with CONFIG_KASAN enabled2. save follow program as test.c```\#include \#include \#include // If string length large than MAX_STRING_SIZE, the fetch_store_strlen()// will return 0, cause __get_data_size() return shorter size, and// store_trace_args() will not trigger out-of-bounds access.// So make string length less than 4096.\#define STRLEN 4093void generate_string(char *str, int n){ int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0';}void print_string(char *str){ printf("%s\n", str);}int main(){ char tmp[STRLEN]; generate_string(tmp, STRLEN); print_string(tmp); return 0;}```3. compile program`gcc -o test test.c`4. get the offset of `print_string()````objdump -t test | grep -w print_string0000000000401199 g F .text 000000000000001b print_string```5. configure uprobe with offset 0x1199```off=0x1199cd /sys/kernel/debug/tracing/echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring" > uprobe_eventsecho 1 > events/uprobes/enableecho 1 > tracing_on```6. run `test`, and kasan will report error.==================================================================BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014Call Trace: dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x27/0x310 kasan_report+0x10f/0x120 ? strncpy_from_user+0x1d6/0x1f0 strncpy_from_user+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 process_fetch_insn+0xb26/0x1470 ? __pfx_process_fetch_insn+0x10/0x10 ? _raw_spin_lock+0x85/0xe0 ? __pfx__raw_spin_lock+0x10/0x10 ? __pte_offset_map+0x1f/0x2d0 ? unwind_next_frame+0xc5f/0x1f80 ? arch_stack_walk+0x68/0xf0 ? is_bpf_text_address+0x23/0x30 ? kernel_text_address.part.0+0xbb/0xd0 ? __kernel_text_address+0x66/0xb0 ? unwind_get_return_address+0x5e/0xa0 ? __pfx_stack_trace_consume_entry+0x10/0x10 ? arch_stack_walk+0xa2/0xf0 ? _raw_spin_lock_irqsave+0x8b/0xf0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? depot_alloc_stack+0x4c/0x1f0 ? _raw_spin_unlock_irqrestore+0xe/0x30 ? stack_depot_save_flags+0x35d/0x4f0 ? kasan_save_stack+0x34/0x50 ? kasan_save_stack+0x24/0x50 ? mutex_lock+0x91/0xe0 ? __pfx_mutex_lock+0x10/0x10 prepare_uprobe_buffer.part.0+0x2cd/0x500 uprobe_dispatcher+0x2c3/0x6a0 ? __pfx_uprobe_dispatcher+0x10/0x10 ? __kasan_slab_alloc+0x4d/0x90 handler_chain+0xdd/0x3e0 handle_swbp+0x26e/0x3d0 ? __pfx_handle_swbp+0x10/0x10 ? uprobe_pre_sstep_notifier+0x151/0x1b0 irqentry_exit_to_user_mode+0xe2/0x1b0 asm_exc_int3+0x39/0x40RIP: 0033:0x401199Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ceRSP: 002b:00007ffdf00576a8 EFLAGS: 00000206RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000 This commit enforces the buffer's maxlen less than a page-size to avoidstore_trace_args() out-of-memory access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50074 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:parport: Proper fix for array out-of-bounds accessThe recent fix for array out-of-bounds accesses replaced sprintf()calls blindly with snprintf(). However, since snprintf() returns thewould-be-printed size, not the actually output size, the lengthcalculation can still go over the given limit.Use scnprintf() instead of snprintf(), which returns the actuallyoutput letters, for addressing the potential out-of-bounds accessproperly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50093 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: intel: int340x: processor: Fix warning during module unloadThe processor_thermal driver uses pcim_device_enable() to enable a PCIdevice, which means the device will be automatically disabled on driverdetach. Thus there is no need to call pci_disable_device() again on it.With recent PCI device resource management improvements, e.g. commitf748a07a0b64 ("PCI: Remove legacy pcim_release()"), this problem isexposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]---Remove the excess pci_disable_device() calls.[ rjw: Subject and changelog edits ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50095 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mad: Improve handling of timed out WRs of mad agentCurrent timeout handler of mad agent acquires/releases mad_agent_privlock for every timed out WRs. This causes heavy locking contentionwhen higher no. of WRs are to be handled inside timeout handler.This leads to softlockup with below trace in some use cases whererdma-cm path is used to establish connection between peer nodesTrace:----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRsand invoke send handler post creating the list. The new method acquires/releases lock once to fetch the list and hence helps to reduce lockingcontetiong when processing higher no. of WRs

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50096 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy errorThe `nouveau_dmem_copy_one` function ensures that the copy push command issent to the device firmware but does not track whether it was executedsuccessfully.In the case of a copy error (e.g., firmware or hardware failure), thecopy push command will be sent via the firmware channel, and`nouveau_dmem_copy_one` will likely report success, leading to the`migrate_to_ram` function returning a dirty HIGH_USER page to the user.This can result in a security vulnerability, as a HIGH_USER page that maycontain sensitive or corrupted data could be returned to the user.To prevent this vulnerability, we allocate a zero page. Thus, in case ofan error, a non-dirty (zero) page will be returned to the user.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50098 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut downThere is a history of deadlock if reboot is performed at the beginningof booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFSshutdown, and at that time the audio driver was waiting onblk_mq_submit_bio() holding a mutex_lock while reading the fw binary.After that, a deadlock issue occurred while audio driver shutdown waswaiting for mutex_unlock of blk_mq_submit_bio(). To solve this, setSDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes downafter a UFS shutdown will return an error.[ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown][ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49][ 31.907806]I[0: swapper/0: 0] Call trace:[ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338[ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc[ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8[ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40[ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac[ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24[ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec[ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280[ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c[ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280[ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158[ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4[ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0[ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0[ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4[ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4[ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter][ 31.908783]I[0: swapper/0: 0] Call trace:[ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338[ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc[ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8[ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178[ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c[ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50099 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: probes: Remove broken LDR (literal) uprobe supportThe simulate_ldr_literal() and simulate_ldrsw_literal() functions areunsafe to use for uprobes. Both functions were originally written foruse with kprobes, and access memory with plain C accesses. When uprobeswas added, these were reused unmodified even though they cannot safelyaccess user memory.There are three key problems:1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()).2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN.3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers.Practically speaking, (1) and (2) are the big issues. Given there havebeen no reports of problems since the broken code was introduced, itappears that no-one is relying on probing these instructions withuprobes.Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW(literal), limiting the use of simulate_ldr_literal() andsimulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR(literal) and LDRSW (literal) will be rejected asarm_probe_decode_insn() will return INSN_REJECTED. In future we canconsider introducing working uprobes support for these instructions, butthis will require more significant work.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50103 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() couldpossibly return NULL pointer. NULL Pointer Dereference may betriggerred without addtional check.Add a NULL check for the returned pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50110 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: fix one more kernel-infoleak in algo dumpingDuring fuzz testing, the following issue was discovered:BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81Uninit was stored to memory at: copy_to_user_state_extra+0xcc1/0x1e00 dump_one_state+0x28c/0x5f0 xfrm_state_walk+0x548/0x11e0 xfrm_dump_sa+0x1e0/0x840 netlink_dump+0x943/0x1c40 __netlink_dump_start+0x746/0xdb0 xfrm_user_rcv_msg+0x429/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81Uninit was created at: __kmalloc+0x571/0xd30 attach_auth+0x106/0x3e0 xfrm_add_sa+0x2aa0/0x4230 xfrm_user_rcv_msg+0x832/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81Bytes 328-379 of 732 are uninitializedMemory access of size 732 starts at ffff88800e18e000Data copied to user address 00007ff30f48aff0CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Fixes copying of xfrm algorithms where some randomdata of the structure fields can end up in userspace.Padding in structures may be filled with random (possibly sensitve)data and should never be given directly to user-space.A similar issue was resolved in the commit8222d5910dae ("xfrm: Zero padding when dumping algos and encap")Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50131 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Consider the NULL character when validating the event lengthstrlen() returns a string length excluding the null byte. If the stringlength equals to the maximum buffer length, the buffer will have nospace for the NULL terminating character.This commit checks this condition and returns failure for it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50151 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix OOBs when building SMB2_IOCTL requestWhen using encryption, either enforced by the server or when using'seal' mount option, the client will squash all compound request buffersdown for encryption into a single iov in smb2_set_next_command().SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold theSMB2_IOCTL request in the first iov, and if the user passes an inputbuffer that is greater than 328 bytes, smb2_set_next_command() willend up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50166 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fsl/fman: Fix refcount handling of fman-related devicesIn mac_probe() there are multiple calls to of_find_device_by_node(),fman_bind() and fman_port_bind() which takes references to of_dev->dev.Not all references taken by these calls are released later on error pathin mac_probe() and in mac_remove() which lead to reference leaks.Add references release.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50167 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:be2net: fix potential memory leak in be_xmit()The be_xmit() returns NETDEV_TX_OK without freeing skbin case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50179 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ceph: remove the incorrect Fw reference check when dirtying pagesWhen doing the direct-io reads it will also try to mark pages dirty,but for the read path it won't hold the Fw caps and there is casewill it get the Fw reference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50182 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:secretmem: disable memfd_secret() if arch cannot set direct mapReturn -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). Thisis the case for example on some arm64 configurations, where marking 4kPTEs in the direct map not present can only be done if the direct map isset up at 4k granularity in the first place (as ARM's break-before-makesemantics do not easily allow breaking apart large/gigantic pages).More precisely, on arm64 systems with !can_set_direct_map(),set_direct_map_invalid_noflush() is a no-op, however it returns success(0) instead of an error. This means that memfd_secret will seemingly"work" (e.g. syscall succeeds, you can mmap the fd and fault in pages),but it does not actually achieve its goal of removing its memory from thedirect map.Note that with this patch, memfd_secret() will start erroring on systemswhere can_set_direct_map() returns false (arm64 withCONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n andCONFIG_KFENCE=n), but that still seems better than the current silentfailure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', mostarm64 systems actually have a working memfd_secret() and aren't beaffected.From going through the iterations of the original memfd_secret patchseries, it seems that disabling the syscall in these scenarios was theintended behavior [1] (preferred over havingset_direct_map_invalid_noflush return an error as that would result inSIGBUSes at page-fault time), however the check for it got dropped betweenv16 [2] and v17 [3], when secretmem moved away from CMA allocations.[1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/[2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t[3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50185 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: handle consistently DSS corruptionBugged peer implementation can send corrupted DSS options, consistentlyhitting a few warning in the data path. Use DEBUG_NET assertions, toavoid the splat on some builds and handle consistently the error, dumpingrelated MIBs and performing fallback and/or reset according to thesubflow type.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50186 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: explicitly clear the sk pointer, when pf->create failsWe have recently noticed the exact same KASAN splat as in commit6cd4a78d962b ("net: do not leave a dangling sk pointer, when socketcreation fails"). The problem is that commit did not fully address theproblem, as some pf->create implementations do not use sk_common_releasein their error paths.For example, we can use the same reproducer as in the above commit, butchanging ping to arping. arping uses AF_PACKET socket and if packet_createfails, it will just sk_free the allocated sk object.While we could chase all the pf->create implementations and make sure theyNULL the freed sk object on error from the socket, we can't guaranteefuture protocols will not make the same mistake.So it is easier to just explicitly NULL the sk pointer upon return frompf->create in __sock_create. We do know that pf->create always releases theallocated sk object on error, so if the pointer is not NULL, it isdefinitely dangling.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50187 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: Stop the active perfmon before being destroyedUpon closing the file descriptor, the active performance monitor is notstopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,the active performance monitor's pointer (`vc4->active_perfmon`) is stillretained.If we open a new file descriptor and submit a few jobs with performancemonitors, the driver will attempt to stop the active performance monitorusing the stale pointer in `vc4->active_perfmon`. However, this pointeris no longer valid because the previous process has already terminated,and all performance monitors associated with it have been destroyed andfreed.To fix this, when the active performance monitor belongs to a givenprocess, explicitly stop it before destroying and freeing it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50192 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v4: Don't allow a VMOVP on a dying VPEKunkun Jiang reported that there is a small window of opportunity foruserspace to force a change of affinity for a VPE while the VPE has alreadybeen unmapped, but the corresponding doorbell interrupt still visible in/proc/irq/.Plug the race by checking the value of vmapp_count, which tracks whetherthe VPE is mapped ot not, and returning an error in this case.This involves making vmapp_count common to both GICv4.1 and its v4.0ancestor.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50195 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:posix-clock: Fix missing timespec64 check in pc_clock_settime()As Andrew pointed out, it will make sense that the PTP corechecked timespec64 struct's tv_sec and tv_nsec range before callingptp->info->settime64().As the man manual of clock_settime() said, if tp.tv_sec is negative ortp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,which include dynamic clocks which handles PTP clock, and the condition isconsistent with timespec64_valid(). As Thomas suggested, timespec64_valid()only check the timespec is valid, but not ensure that the time isin a valid range, so check it ahead using timespec64_valid_strict()in pc_clock_settime() and return -EINVAL if not valid.There are some drivers that use tp->tv_sec and tp->tv_nsec directly towrite registers without validity checks and assume that the higher layerhas checked it, which is dangerous and will benefit from this, such ashclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),and some drivers can remove the checks of itself.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50196 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: ocelot: fix system hang on level based interruptsThe current implementation only calls chained_irq_enter() andchained_irq_exit() if it detects pending interrupts.```for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, ®); if (!reg) continue; chained_irq_enter(parent_chip, desc);```However, in case of GPIO pin configured in level mode and the parentcontroller configured in edge mode, GPIO interrupt might be lowered by thehardware. In the result, if the interrupt is short enough, the parentinterrupt is still pending while the GPIO interrupt is cleared;chained_irq_enter() never gets called and the system hangs trying toservice the parent interrupt.Moving chained_irq_enter() and chained_irq_exit() outside the for loopensures that they are called even when GPIO interrupt is lowered by thehardware.The similar code with chained_irq_enter() / chained_irq_exit() functionswrapping interrupt checking loop may be found in many other drivers:```grep -r -A 10 chained_irq_enter drivers/pinctrl```

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50201 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: Fix encoder->possible_clonesInclude the encoder itself in its possible_clones bitmask.In the past nothing validated that drivers were populatingpossible_clones correctly, but that changed in commit74d2aacbe840 ("drm: Validate encoder->possible_clones").Looks like radeon never got the memo and is still notfollowing the rules 100% correctly.This results in some warnings during driver initialization:Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7)WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c...(cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50202 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: propagate directory read errors from nilfs_find_entry()Syzbot reported that a task hang occurs in vcs_open() during a fuzzingtest for nilfs2.The root cause of this problem is that in nilfs_find_entry(), whichsearches for directory entries, ignores errors when loading a directorypage/folio via nilfs_get_folio() fails.If the filesystem images is corrupted, and the i_size of the directoryinode is large, and the directory page/folio is successfully read butfails the sanity check, for example when it is zero-filled,nilfs_check_folio() may continue to spit out error messages in bursts.Fix this issue by propagating the error to the callers when loading apage/folio fails in nilfs_find_entry().The current interface of nilfs_find_entry() and its callers is outdatedand cannot propagate error codes such as -EIO and -ENOMEM returned vianilfs_find_entry(), so fix it together.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50218 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: pass u64 to ocfs2_truncate_inline maybe overflowSyzbot reported a kernel BUG in ocfs2_truncate_inline. There are tworeasons for this: first, the parameter value passed is greater thanocfs2_max_inline_data_with_xattr, second, the start and end parameters ofocfs2_truncate_inline are "unsigned int".So, we need to add a sanity check for byte_start and byte_len right beforeocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greaterthan ocfs2_max_inline_data_with_xattr return -EINVAL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: do not pass a stopped vif to the driver in .get_txpowerAvoid potentially crashing in the driver because of uninitialized private data

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50251 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_payload: sanitize offset and length before calling skb_checksum()If access to offset + length is larger than the skbuff length, thenskb_checksum() triggers BUG_ON().skb_checksum() internally subtracts the length parameter while iteratingover skbuff, BUG_ON(len) at the end of it checks that the expectedlength to be included in the checksum calculation is fully consumed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50256 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()I got a syzbot report without a repro [1] crashing in nf_send_reset6()I think the issue is that dev->hard_header_len is zero, and we attemptlater to push an Ethernet header.Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.[1]skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3RSP: 0018:ffffc900045269b0 EFLAGS: 00010282RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4cccR10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003cFS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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/0x7fRIP: 0033:0x7fdbeeb7d1ffCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 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 1c 8e 02 00 48RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ffRDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8RBP: 00007fdbeebf12be R08: 0000000---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50258 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix crash when config small gso_max_size/gso_ipv4_max_sizeConfig a small gso_max_size/gso_ipv4_max_size will lead to an underflowin sk_dst_gso_max_size(), which may trigger a BUG_ON crash,because sk->sk_gso_max_size would be much bigger than device limits.Call Trace:tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs)Add check for the minimum value of gso_max_size and gso_ipv4_max_size.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50271 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:signal: restore the override_rlimit logicPrior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top ofucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class ofsignals. However now it's enforced unconditionally, even ifoverride_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGVsignal, sigqueue_alloc fails to allocate the necessary resources for thesignal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address andhandling the error. From the user-space perspective, applications areunaware that the limit has been reached and that the siginfo iseffectively 'corrupted'. This can lead to unpredictable behavior andcrashes, as we observed with java applications.Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skipthe comparison to max there if override_rlimit is set. This effectivelyrestores the old behavior.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50272 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:filemap: Fix bounds checking in filemap_read()If the caller supplies an iocb->ki_pos value that is close to thefilesystem upper limit, and an iterator with a count that causes us tooverflow that limit, then filemap_read() enters an infinite loop.This behaviour was discovered when testing xfstests generic/525 with the"localio" optimisation for loopback NFS mounts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50273 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reinitialize delayed ref list after deleting it from the listAt insert_delayed_ref() if we need to update the action of an existingref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head'sref_add_list using list_del(), which leaves the ref's add_list membernot reinitialized, as list_del() sets the next and prev members of thelist to LIST_POISON1 and LIST_POISON2, respectively.If later we end up calling drop_delayed_ref() against the ref, which canhappen during merging or when destroying delayed refs due to a transactionabort, we can trigger a crash since at drop_delayed_ref() we calllist_empty() against the ref's add_list, which returns false sincethe list was not reinitialized after the list_del() and as a consequencewe call list_del() again at drop_delayed_ref(). This results in aninvalid list access since the next and prev members are set to poisonpointers, resulting in a splat if CONFIG_LIST_HARDENED andCONFIG_DEBUG_LIST are set or invalid poison pointer dereferencesotherwise.So fix this by deleting from the list with list_del_init() instead.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50287 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-tpg: prevent the risk of a division by zeroAs reported by Coverity, the logic at tpg_precalculate_line()blindly rescales the buffer even when scaled_witdh is equal tozero. If this ever happens, this will cause a division by zero.Instead, add a WARN_ON_ONCE() to trigger such cases and returnwithout doing any precalculation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50289 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: av7110: fix a spectre vulnerabilityAs warned by smatch: drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap)There is a spectre-related vulnerability at the code. Fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50298 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: allocate vf_state during PF probesIn the previous implementation, vf_state is allocated memory only when VFis enabled. However, net_device_ops::ndo_set_vf_mac() may be called beforeVF is enabled to configure the MAC address of VF. If this is the case,enetc_pf_set_vf_mac() will access vf_state, resulting in access to a nullpointer. The simplified error log is as follows.root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89[ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004[ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy[ 173.641973] lr : do_setlink+0x4a8/0xec8[ 173.732292] Call trace:[ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80[ 173.738847] __rtnl_newlink+0x530/0x89c[ 173.742692] rtnl_newlink+0x50/0x7c[ 173.746189] rtnetlink_rcv_msg+0x128/0x390[ 173.750298] netlink_rcv_skb+0x60/0x130[ 173.754145] rtnetlink_rcv+0x18/0x24[ 173.757731] netlink_unicast+0x318/0x380[ 173.761665] netlink_sendmsg+0x17c/0x3c8

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-50304 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()The per-netns IP tunnel hash table is protected by the RTNL mutex andip_tunnel_find() is only called from the control path where the mutex istaken.Add a lockdep expression to hlist_for_each_entry_rcu() inip_tunnel_find() in order to validate that the mutex is held and tosilence the suspicious RCU usage warning [1].[1]WARNING: suspicious RCU usage6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted-----------------------------net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60stack backtrace:CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-52332 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:igb: Fix potential invalid memory access in igb_init_module()The pci_register_driver() can fail and when this happened, the dca_notifierneeds to be unregistered, otherwise the dca_notifier can be called whenigb fails to install, resulting to invalid memory access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-52559 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()The "submit->cmd[i].size" and "submit->cmd[i].offset" variables are u32values that come from the user via the submit_lookup_cmds() function.This addition could lead to an integer wrapping bug so use size_add()to prevent that.Patchwork: https://patchwork.freedesktop.org/patch/624696/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53050 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/hdcp: Add encoder check in hdcp2_get_capabilityAdd encoder check in intel_hdcp2_get_capability to avoidnull pointer error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53051 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/hdcp: Add encoder check in intel_hdcp_get_capabilitySometimes during hotplug scenario or suspend/resume scenario encoder isnot always initialized when intel_hdcp_get_capability adda check to avoid kernel null pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53055 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: fix 6 GHz scan constructionIf more than 255 colocated APs exist for the set of allAPs found during 2.4/5 GHz scanning, then the 6 GHz scanconstruction will loop forever since the loop variablehas type u8, which can never reach the number found whenthat's bigger than 255, and is stored in a u32 variable.Also move it into the loops to have a smaller scope.Using a u32 there is fine, we limit the number of APs inthe scan list and each has a limit on the number of RNRentries due to the frame size. With a limit of 1000 scanresults, a frame size upper bound of 4096 (really it'smore like ~2300) and a TBTT entry size of at least 11,we get an upper bound for the number of ~372k, well inthe bounds of a u32.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53058 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB dataIn case the non-paged data of a SKB carries protocol header and protocolpayload to be transmitted on a certain platform that the DMA AXI addresswidth is configured to 40-bit/48-bit, or the size of the non-paged datais bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXIaddress width is configured to 32-bit, then this SKB requires at leasttwo DMA transmit descriptors to serve it.For example, three descriptors are allocated to split one DMA buffermapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2].Then three elements of tx_q->tx_skbuff_dma[] will be allocated to holdextra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2].Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA bufferaddress returned by DMA mapping call. stmmac_tx_clean() will try tounmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].bufis a valid buffer address.The expected behavior that saves DMA buffer address of this non-pageddata to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single();Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL;On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by theDMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer addressobviously, then the DMA buffer will be unmapped immediately.There may be a rare case that the DMA engine does not finish thepending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will gohorribly wrong, DMA is going to access a unmapped/unreferenced memoryregion, corrupted data will be transmited or iommu fault will betriggered :(In contrast, the for-loop that maps SKB fragments behaves perfectlyas expected, and that is how the driver should do for both non-pageddata and paged frags actually.This patch corrects DMA map/unmap sequences by fixing the array indexfor tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address.Tested and verified on DWXGMAC CORE 3.20a

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53066 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfs: Fix KMSAN warning in decode_getfattr_attrs()Fix the following KMSAN warning:CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G BTainted: [B]=BAD_PAGEHardware name: QEMU Standard PC (Q35 + ICH9, 2009)==========================================================================================================BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe KMSAN warning is triggered in decode_getfattr_attrs(), when callingdecode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is notinitialized.Fix the issue by initializing fattr->mdsthreshold to NULL innfs_fattr_init().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix lock recursionafs_wake_up_async_call() can incur lock recursion. The problem is that itis called from AF_RXRPC whilst holding the ->notify_lock, but it tries totake a ref on the afs_call struct in order to pass it to a work queue - butif the afs_call is already queued, we then have an extraneous ref that mustbe put... calling afs_put_call() may call back down into AF_RXRPC throughrxrpc_kernel_shutdown_call(), however, which might try taking the->notify_lock again.This case isn't very common, however, so defer it to a workqueue. The oopslooks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53103 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointerWhen hvs is released, there is a possibility that vsk->trans may notbe initialized to NULL, which could lead to a dangling pointer.This issue is resolved by initializing vsk->trans to NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53112 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: uncache inode which has failed entering the groupSyzbot has reported the following BUG:kernel BUG at fs/ocfs2/uptodate.c:509!...Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particularinode in 'ocfs2_verify_group_and_input()', corresponding buffer headremains cached and subsequent call to the same 'ioctl()' for the sameinode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (tryingto cache the same buffer head of that inode). Fix this by uncachingthe buffer head with 'ocfs2_remove_from_cache()' on error path in'ocfs2_group_add()'.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53113 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: fix NULL pointer dereference in alloc_pages_bulk_noprofWe triggered a NULL pointer dereference for ac.preferred_zoneref->zone inalloc_pages_bulk_noprof() when the task is migrated between cpusets.When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be¤t->mems_allowed. when first_zones_zonelist() is called to findpreferred_zoneref, the ac->nodemask may be modified concurrently if thetask is migrated between different cpusets. Assuming we have 2 NUMA Node,when traversing Node1 in ac->zonelist, the nodemask is 2, and whentraversing Node2 in ac->zonelist, the nodemask is 1. As a result, theac->preferred_zoneref points to NULL zone.In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds aallowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leadingto NULL pointer dereference.__alloc_pages_noprof() fixes this issue by checking NULL pointer in commitea57485af8f4 ("mm, page_alloc: fix check for NULL preferred_zone") andcommit df76cee6bbeb ("mm, page_alloc: remove redundant checks from allocfastpath").To fix it, check NULL pointer for preferred_zoneref->zone.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53119 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virtio/vsock: Fix accept_queue memory leakAs the final stages of socket destruction may be delayed, it is possiblethat virtio_transport_recv_listen() will be called after the accept_queuehas been flushed, but before the SOCK_DONE flag has been set. As a result,sockets enqueued after the flush would remain unremoved, leading to amemory leak.vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK(!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) releaseclose_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound releaseIntroduce a sk_shutdown check to disallow vsock_enqueue_accept() duringsocket destruction.unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53120 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: CT: Fix null-ptr-deref in add rule err flowIn error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add()callback returns error, zone_rule->attr is used uninitiated. Fix it touse attr which has the needed pointer value.Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]... Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53121 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fs, lock FTE when checking if activeThe referenced commits introduced a two-step process for deleting FTEs:- Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE.- Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray.However, this approach encounters a race condition if a rule with the samematch value is added simultaneously. In this scenario, fs_core may set thehardware deletion function to NULL prematurely, causing a panic duringsubsequent rule deletions.To prevent this, ensure the active flag of the FTE is checked under a lock,which will prevent the fs_core layer from attaching a new steering rule toan FTE that is in the process of deletion.[ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func[ 438.968205] ------------[ cut here ]------------[ 438.968654] refcount_t: decrement hit 0; leaking memory.[ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110[ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower][ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8[ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110[ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90[ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286[ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000[ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0[ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0[ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0[ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0[ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000[ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0[ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 438.986507] Call Trace:[ 438.986799] [ 438.987070] ? __warn+0x7d/0x110[ 438.987426] ? refcount_warn_saturate+0xfb/0x110[ 438.987877] ? report_bug+0x17d/0x190[ 438.988261] ? prb_read_valid+0x17/0x20[ 438.988659] ? handle_bug+0x53/0x90[ 438.989054] ? exc_invalid_op+0x14/0x70[ 438.989458] ? asm_exc_invalid_op+0x16/0x20[ 438.989883] ? refcount_warn_saturate+0xfb/0x110[ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core][ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core][ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core][ 438.992054] ? xas_load+0x9/0xb0[ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core][ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core][ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core][ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core][ 438.994728] tc_setup_cb_destroy+0xb9/0x190[ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower][ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower][ 438.996105] tc_new_tfilter+0x347/0xbc0[ 438.996503] ? __---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53122 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: cope racing subflow creation in mptcp_rcv_space_adjustAdditional active subflows - i.e. created by the in kernel pathmanager - are included into the subflow list before starting the3whs.A racing recvmsg() spooling data received on an already establishedsubflow would unconditionally call tcp_cleanup_rbuf() on all thecurrent subflows, potentially hitting a divide by zero error onthe newly created ones.Explicitly check that the subflow is in a suitable state beforeinvoking tcp_cleanup_rbuf().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53129 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/rockchip: vop: Fix a dereferenced before check warningThe 'state' can't be NULL, we should check crtc_state.Fix warning:drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096vop_plane_atomic_async_check() warn: variable dereferenced before check'state' (see line 1077)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53130 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix null-ptr-deref in block_dirty_buffer tracepointWhen using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty()may cause a NULL pointer dereference, or a general protection fault whenKASAN is enabled.This happens because, since the tracepoint was added inmark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_devregardless of whether the buffer head has a pointer to a block_devicestructure.In the current implementation, nilfs_grab_buffer(), which grabs a bufferto read (or create) a block of metadata, including b-tree node blocks,does not set the block device, but instead does so only if the buffer isnot in the "uptodate" state for each of its caller block readingfunctions. However, if the uptodate flag is set on a folio/page, and thebuffer heads are detached from it by try_to_free_buffers(), and new bufferheads are then attached by create_empty_buffers(), the uptodate flag maybe restored to each buffer without the block device being set tobh->b_bdev, and mark_buffer_dirty() may be called later in that state,resulting in the bug mentioned above.Fix this issue by making nilfs_grab_buffer() always set the block deviceof the super block structure to the buffer head, regardless of the stateof the buffer's uptodate flag.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53131 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix null-ptr-deref in block_touch_buffer tracepointPatch series "nilfs2: fix null-ptr-deref bugs on block tracepoints".This series fixes null pointer dereference bugs that occur when usingnilfs2 and two block-related tracepoints.This patch (of 2):It has been reported that when using "block:block_touch_buffer"tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes aNULL pointer dereference, or a general protection fault when KASAN isenabled.This happens because since the tracepoint was added in touch_buffer(), itreferences the dev_t member bh->b_bdev->bd_dev regardless of whether thebuffer head has a pointer to a block_device structure. In the currentimplementation, the block_device structure is set after the functionreturns to the caller.Here, touch_buffer() is used to mark the folio/page that owns the bufferhead as accessed, but the common search helper for folio/page used by thecaller function was optimized to mark the folio/page as accessed when itwas reimplemented a long time ago, eliminating the need to calltouch_buffer() here in the first place.So this solves the issue by eliminating the touch_buffer() call itself.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53140 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: terminate outstanding dump on socket closeNetlink supports iterative dumping of data. It provides the familiesthe following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanupThe whole process is asynchronous and the repeated calls to .dumpdon't actually happen in a tight loop, but rather are triggeredin response to recvmsg() on the socket.This gives the user full control over the dump, but also means thatthe user can close the socket without getting to the end of the dump.To make sure .start is always paired with .done we check if thereis an ongoing dump before freeing the socket, and if so call .done.The complication is that sockets can get freed from BH and .doneis allowed to sleep. So we use a workqueue to defer the call, whenneeded.Unfortunately this does not work correctly. What we defer is notthe cleanup but rather releasing a reference on the socket.We have no guarantee that we own the last reference, if someoneelse holds the socket they may release it in BH and we're backto square one.The whole dance, however, appears to be unnecessary. Only the usercan interact with dumps, so we can clean up when socket is closed.And close always happens in process context. Some async code maystill access the socket after close, queue notification skbs to it etc.but no dumps can start, end or otherwise make progress.Delete the workqueue and flush the dump state directly from the releasehandler. Note that further cleanup is possible in -next, for instancewe now always call .done before releasing the main module reference,so dump doesn't have to take a reference of its own.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53157 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scpi: Check the DVFS OPP count returned by the firmwareFix a kernel crash with the below call trace when the SCPI firmwarereturns OPP count of zero.dvfs_info.opp_count may be zero on some platforms during the reboottest, and the kernel will crash after dereferencing the pointer tokcalloc(info->count, sizeof(*opp), GFP_KERNEL). | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53172 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ubi: fastmap: Fix duplicate slab cache names while attachingSince commit 4c39529663b9 ("slab: Warn on duplicate cache names whenDEBUG_VM=y"), the duplicate slab cache names can be detected and akernel WARNING is thrown out.In UBI fast attaching process, alloc_ai() could be invoked twicewith the same slab cache name 'ubi_aeb_slab_cache', which will triggerfollowing warning messages: kmem_cache of name 'ubi_aeb_slab_cache' already exists WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107 __kmem_cache_create_args+0x100/0x5f0 Modules linked in: ubi(+) nandsim [last unloaded: nandsim] CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0 Call Trace: __kmem_cache_create_args+0x100/0x5f0 alloc_ai+0x295/0x3f0 [ubi] ubi_attach+0x3c3/0xcc0 [ubi] ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi] ubi_init+0x3fb/0x800 [ubi] do_init_module+0x265/0x7d0 __x64_sys_finit_module+0x7a/0xc0The problem could be easily reproduced by loading UBI device by fastmapwith CONFIG_DEBUG_VM=y.Fix it by using different slab names for alloc_ai() callers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53174 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: make sure cache entry active before cache_showThe function `c_show` was called with protection from RCU. This onlyensures that `cp` will not be freed. Therefore, the reference count for`cp` can drop to zero, which will trigger a refcount use-after-freewarning when `cache_get` is called. To resolve this issue, use`cache_get_rcu` to ensure that `cp` remains active.------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 7 PID: 822 at lib/refcount.c:25refcount_warn_saturate+0xb1/0x120CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014RIP: 0010:refcount_warn_saturate+0xb1/0x120Call Trace: c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53180 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Add sanity NULL check for the default mmap fault handlerA driver might allow the mmap access before initializing itsruntime->dma_area properly. Add a proper NULL check before passing tovirt_to_page() for avoiding a panic.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53183 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:um: net: Do not use drvdata in releaseThe drvdata is not available in release. Let's just use container_of()to get the uml_net instance. Otherwise, removing a network device willresult in a crash:RIP: 0033:net_device_release+0x10/0x6fRSP: 00000000e20c7c40 EFLAGS: 00010206RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6Kernel panic - not syncing: Segfault with no mmCPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1Workqueue: events mc_work_procStack: 627af028 62c7af00 e20c7c80 60276fcd 62778000 603f5820 627af028 00000000 e20c7cb0 603a2bcd 627af000 62770010Call Trace: [<60276fcd>] device_release+0x70/0xba [<603a2bcd>] kobject_put+0xba/0xe7 [<60277265>] put_device+0x19/0x1c [<60281266>] platform_device_put+0x26/0x29 [<60281e5f>] platform_device_unregister+0x2c/0x2e [<6002ec9c>] net_remove+0x63/0x69 [<60031316>] ? mconsole_reply+0x0/0x50 [<600310c8>] mconsole_remove+0x160/0x1cc [<60087d40>] ? __remove_hrtimer+0x38/0x74 [<60087ff8>] ? hrtimer_try_to_cancel+0x8c/0x98 [<6006b3cf>] ? dl_server_stop+0x3f/0x48 [<6006b390>] ? dl_server_stop+0x0/0x48 [<600672e8>] ? dequeue_entities+0x327/0x390 [<60038fa6>] ? um_set_signals+0x0/0x43 [<6003070c>] mc_work_proc+0x77/0x91 [<60057664>] process_scheduled_works+0x1b3/0x2dd [<60055f32>] ? assign_work+0x0/0x58 [<60057f0a>] worker_thread+0x1e9/0x293 [<6005406f>] ? set_pf_worker+0x0/0x64 [<6005d65d>] ? arch_local_irq_save+0x0/0x2d [<6005d748>] ? kthread_exit+0x0/0x3a [<60057d21>] ? worker_thread+0x0/0x293 [<6005dbf1>] kthread+0x126/0x12b [<600219c5>] new_thread_handler+0x85/0xb6

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53184 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:um: ubd: Do not use drvdata in releaseThe drvdata is not available in release. Let's just use container_of()to get the ubd instance. Otherwise, removing a ubd device will resultin a crash:RIP: 0033:blk_mq_free_tag_set+0x1f/0xbaRSP: 00000000e2083bf0 EFLAGS: 00010246RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0Kernel panic - not syncing: Segfault with no mmCPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1Workqueue: events mc_work_procStack: 00000000 604f7ef0 62c5d000 62405d20 e2083c30 6002c776 6002c755 600e47ff e2083c60 6025ffe3 04208060 603d36e0Call Trace: [<6002c776>] ubd_device_release+0x21/0x55 [<6002c755>] ? ubd_device_release+0x0/0x55 [<600e47ff>] ? kfree+0x0/0x100 [<6025ffe3>] device_release+0x70/0xba [<60381d6a>] kobject_put+0xb5/0xe2 [<6026027b>] put_device+0x19/0x1c [<6026a036>] platform_device_put+0x26/0x29 [<6026ac5a>] platform_device_unregister+0x2c/0x2e [<6002c52e>] ubd_remove+0xb8/0xd6 [<6002bb74>] ? mconsole_reply+0x0/0x50 [<6002b926>] mconsole_remove+0x160/0x1cc [<6002bbbc>] ? mconsole_reply+0x48/0x50 [<6003379c>] ? um_set_signals+0x3b/0x43 [<60061c55>] ? update_min_vruntime+0x14/0x70 [<6006251f>] ? dequeue_task_fair+0x164/0x235 [<600620aa>] ? update_cfs_group+0x0/0x40 [<603a0e77>] ? __schedule+0x0/0x3ed [<60033761>] ? um_set_signals+0x0/0x43 [<6002af6a>] mc_work_proc+0x77/0x91 [<600520b4>] process_scheduled_works+0x1af/0x2c3 [<6004ede3>] ? assign_work+0x0/0x58 [<600527a1>] worker_thread+0x2f7/0x37a [<6004ee3b>] ? set_pf_worker+0x0/0x64 [<6005765d>] ? arch_local_irq_save+0x0/0x2d [<60058e07>] ? kthread_exit+0x0/0x3a [<600524aa>] ? worker_thread+0x0/0x37a [<60058f9f>] kthread+0x130/0x135 [<6002068e>] new_thread_handler+0x85/0xb6

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53185 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix NULL ptr deref in crypto_aead_setkey()Neither SMB3.0 or SMB3.02 supports encryption negotiate context, sowhen SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,the client uses AES-128-CCM as the default cipher. See MS-SMB23.3.5.4.Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") addeda @server->cipher_type check to conditionally callsmb3_crypto_aead_allocate(), but that check would always be false as@server->cipher_type is unset for SMB3.02.Fix the following KASAN splat by setting @server->cipher_type forSMB3.02 as well.mount.cifs //srv/share /mnt -o vers=3.02,seal,...BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130Read of size 8 at addr 0000000000000020 by task mount.cifs/1095CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc4104/01/2014Call Trace: dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfx___lock_acquire+0x10/0x10 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53210 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount(skb->users) and iucv_sock_recvmsg() does not decrement skb refcountat exit.This results in skb memory leak in skb_queue_purge() and WARN_ON iniucv_sock_destruct() during socket close. To fix this decreaseskb refcount by one if MSG_PEEK is set in order to prevent memoryleak and WARN_ON.WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53215 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()There's issue as follows:RPC: Registered rdma transport module.RPC: Registered rdma backchannel transport module.RPC: Unregistered rdma transport module.RPC: Unregistered rdma backchannel transport module.BUG: unable to handle page fault for address: fffffbfff80c609aPGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTIRIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0Call Trace: __die+0x1f/0x70 page_fault_oops+0x2cd/0x860 spurious_kernel_fault+0x36/0x450 do_kern_addr_fault+0xca/0x100 exc_page_fault+0x128/0x150 asm_exc_page_fault+0x26/0x30 percpu_counter_destroy_many+0xf7/0x2a0 mmdrop+0x209/0x350 finish_task_switch.isra.0+0x481/0x840 schedule_tail+0xe/0xd0 ret_from_fork+0x23/0x80 ret_from_fork_asm+0x1a/0x30 If register_sysctl() return NULL, then svc_rdma_proc_cleanup() will notdestroy the percpu counters which init in svc_rdma_proc_init().If CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the'percpu_counters' list. The above issue may occur once the module isremoved. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memoryleakage occurs.To solve above issue just destroy all percpu counters whenregister_sysctl() return NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53217 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Prevent NULL dereference in nfsd4_process_cb_update()@ses is initialized to NULL. If __nfsd4_find_backchannel() finds noavailable backchannel session, setup_callback_client() will try todereference @ses and segfault.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53219 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virtiofs: use pages instead of pointer for kernel direct IOWhen trying to insert a 10MB kernel module kept in a virtio-fs with cachedisabled, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ...... Call Trace: ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160 __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230 __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... ---[ end trace 0000000000000000 ]---The warning is triggered as follows:1) syscall finit_module() handles the module insertion and it invokeskernel_read_file() to read the content of the module first.2) kernel_read_file() allocates a 10MB buffer by using vmalloc() andpasses it to kernel_read(). kernel_read() constructs a kvec iter byusing iov_iter_kvec() and passes it to fuse_file_read_iter().3) virtio-fs disables the cache, so fuse_file_read_iter() invokesfuse_direct_io(). As for now, the maximal read size for kvec iter isonly limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, sofuse_direct_io() doesn't split the 10MB buffer. It saves the address andthe size of the 10MB-sized buffer in out_args[0] of a fuse request andpasses the fuse request to virtio_fs_wake_pending_and_unlock().4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() toqueue the request. Because virtiofs need DMA-able address, sovirtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer forall fuse args, copies these args into the bounce buffer and passed thephysical address of the bounce buffer to virtiofsd. The total length ofthese fuse args for the passed fuse request is about 10MB, socopy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter andit triggers the warning in __alloc_pages(): if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) return NULL;5) virtio_fs_enqueue_req() will retry the memory allocation in akworker, but it won't help, because kmalloc() will always return NULLdue to the abnormal size and finit_module() will hang forever.A feasible solution is to limit the value of max_read for virtio-fs, sothe length passed to kmalloc() will be limited. However it will affectthe maximal read size for normal read. And for virtio-fs write initiatedfrom kernel, it has the similar problem but now there is no way to limitfc->max_write in kernel.So instead of limiting both the values of max_read and max_write inkernel, introducing use_pages_for_kvec_io in fuse_conn and setting it astrue in virtiofs. When use_pages_for_kvec_io is enabled, fuse will usepages instead of pointer to pass the KVEC_IO data.After switching to pages for KVEC_IO data, these pages will be used forDMA through virtio-fs. If these pages are backed by vmalloc(),{flush|invalidate}_kernel_vmap_range() are necessary to flush orinvalidate the cache before the DMA operation. So add two new fields infuse_args_pages to record the base address of vmalloc area and thecondition indicating whether invalidation is needed. Perform the flushin fuse_get_user_pages() for write operations and the invalidation infuse_release_user_pages() for read operations.It may seem necessary to introduce another fie---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53220 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to account dirty data in __get_secs_required()It will trigger system panic w/ testcase in [1]:------------[ cut here ]------------kernel BUG at fs/f2fs/segment.c:2752!RIP: 0010:new_curseg+0xc81/0x2110Call Trace: f2fs_allocate_data_block+0x1c91/0x4540 do_write_page+0x163/0xdf0 f2fs_outplace_write_data+0x1aa/0x340 f2fs_do_write_data_page+0x797/0x2280 f2fs_write_single_data_page+0x16cd/0x2190 f2fs_write_cache_pages+0x994/0x1c80 f2fs_write_data_pages+0x9cc/0xea0 do_writepages+0x194/0x7a0 filemap_fdatawrite_wbc+0x12b/0x1a0 __filemap_fdatawrite_range+0xbb/0xf0 file_write_and_wait_range+0xa1/0x110 f2fs_do_sync_file+0x26f/0x1c50 f2fs_sync_file+0x12b/0x1d0 vfs_fsync_range+0xfa/0x230 do_fsync+0x3d/0x80 __x64_sys_fsync+0x37/0x50 x64_sys_call+0x1e88/0x20d0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe root cause is if checkpoint_disabling and lfs_mode are both on,it will trigger OPU for all overwritten data, it may cost more freesegment than expected, so f2fs must account those data correctly tocalculate cosumed free segments later, and return ENOSPC earlier toavoid run out of free segment during block allocation.[1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-53227 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Fix use-after-free in bfad_im_module_exit()BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303Call Trace: dump_stack_lvl+0x95/0xe0 print_report+0xcb/0x620 kasan_report+0xbd/0xf0 __lock_acquire+0x2aca/0x3a20 lock_acquire+0x19b/0x520 _raw_spin_lock+0x2b/0x40 attribute_container_unregister+0x30/0x160 fc_release_transport+0x19/0x90 [scsi_transport_fc] bfad_im_module_exit+0x23/0x60 [bfa] bfad_init+0xdb/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc] bfad_im_module_init+0x17/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x38/0x50 kfree+0x212/0x480 bfad_im_module_init+0x7e/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fAbove issue happens as follows:bfad_init error = bfad_im_module_init() fc_release_transport(bfad_im_scsi_transport_template); if (error) goto ext;ext: bfad_im_module_exit(); fc_release_transport(bfad_im_scsi_transport_template); --> Trigger double releaseDon't call bfad_im_module_exit() if bfad_im_module_init() failed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-54458 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: bsg: Set bsg_queue to NULL after removalCurrently, this does not cause any issues, but I believe it is necessary toset bsg_queue to NULL after removing it to prevent potential use-after-free(UAF) access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-55881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Play nice with protected guests in complete_hypercall_exit()Use is_64_bit_hypercall() instead of is_64_bit_mode() to detect a 64-bithypercall when completing said hypercall. For guests with protected state,e.g. SEV-ES and SEV-SNP, KVM must assume the hypercall was made in 64-bitmode as the vCPU state needed to detect 64-bit mode is unavailable.Hacking the sev_smoke_test selftest to generate a KVM_HC_MAP_GPA_RANGEhypercall via VMGEXIT trips the WARN: ------------[ cut here ]------------ WARNING: CPU: 273 PID: 326626 at arch/x86/kvm/x86.h:180 complete_hypercall_exit+0x44/0xe0 [kvm] Modules linked in: kvm_amd kvm ... [last unloaded: kvm] CPU: 273 UID: 0 PID: 326626 Comm: sev_smoke_test Not tainted 6.12.0-smp--392e932fa0f3-feat #470 Hardware name: Google Astoria/astoria, BIOS 0.20240617.0-0 06/17/2024 RIP: 0010:complete_hypercall_exit+0x44/0xe0 [kvm] Call Trace: kvm_arch_vcpu_ioctl_run+0x2400/0x2720 [kvm] kvm_vcpu_ioctl+0x54f/0x630 [kvm] __se_sys_ioctl+0x6b/0xc0 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56369 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/modes: Avoid divide by zero harder in drm_mode_vrefresh()drm_mode_vrefresh() is trying to avoid divide by zeroby checking whether htotal or vtotal are zero. But we maystill end up with a div-by-zero of vtotal*htotal*...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56538 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm: zynqmp_kms: Unplug DRM device before removalPrevent userspace accesses to the DRM device from causinguse-after-frees by unplugging the device before we remove it. Thiscauses any further userspace accesses to result in an error withoutfurther calls into this driver's internals.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56562 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()if (dev->boardinfo && dev->boardinfo->init_dyn_addr) ^^^ here check "init_dyn_addr" i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...) ^^^^ free "dyn_addr"Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56567 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ad7780: fix division by zero in ad7780_write_raw()In the ad7780_write_raw() , val2 can be zero, which might lead to adivision by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw()is based on iio_info's write_raw. While val is explicitly declared thatcan be zero (in read mode), val2 is not specified to be non-zero.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56575 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Ensure power suppliers be suspended before detach themThe power suppliers are always requested to suspend asynchronously,dev_pm_domain_detach() requires the caller to ensure propersynchronization of this function with power management callbacks.otherwise the detach may led to kernel panic, like below:[ 1457.107934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040[ 1457.116777] Mem abort info:[ 1457.119589] ESR = 0x0000000096000004[ 1457.123358] EC = 0x25: DABT (current EL), IL = 32 bits[ 1457.128692] SET = 0, FnV = 0[ 1457.131764] EA = 0, S1PTW = 0[ 1457.134920] FSC = 0x04: level 0 translation fault[ 1457.139812] Data abort info:[ 1457.142707] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 1457.148196] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 1457.153256] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 1457.158563] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001138b6000[ 1457.165000] [0000000000000040] pgd=0000000000000000, p4d=0000000000000000[ 1457.171792] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 1457.178045] Modules linked in: v4l2_jpeg wave6_vpu_ctrl(-) [last unloaded: mxc_jpeg_encdec][ 1457.186383] CPU: 0 PID: 51938 Comm: kworker/0:3 Not tainted 6.6.36-gd23d64eea511 #66[ 1457.194112] Hardware name: NXP i.MX95 19X19 board (DT)[ 1457.199236] Workqueue: pm pm_runtime_work[ 1457.203247] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 1457.210188] pc : genpd_runtime_suspend+0x20/0x290[ 1457.214886] lr : __rpm_callback+0x48/0x1d8[ 1457.218968] sp : ffff80008250bc50[ 1457.222270] x29: ffff80008250bc50 x28: 0000000000000000 x27: 0000000000000000[ 1457.229394] x26: 0000000000000000 x25: 0000000000000008 x24: 00000000000f4240[ 1457.236518] x23: 0000000000000000 x22: ffff00008590f0e4 x21: 0000000000000008[ 1457.243642] x20: ffff80008099c434 x19: ffff00008590f000 x18: ffffffffffffffff[ 1457.250766] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 63343a6d726f6674[ 1457.257890] x14: 0000000000000004 x13: 00000000000003a4 x12: 0000000000000002[ 1457.265014] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff80008250bbb0[ 1457.272138] x8 : ffff000092937200 x7 : ffff0003fdf6af80 x6 : 0000000000000000[ 1457.279262] x5 : 00000000410fd050 x4 : 0000000000200000 x3 : 0000000000000000[ 1457.286386] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008590f000[ 1457.293510] Call trace:[ 1457.295946] genpd_runtime_suspend+0x20/0x290[ 1457.300296] __rpm_callback+0x48/0x1d8[ 1457.304038] rpm_callback+0x6c/0x78[ 1457.307515] rpm_suspend+0x10c/0x570[ 1457.311077] pm_runtime_work+0xc4/0xc8[ 1457.314813] process_one_work+0x138/0x248[ 1457.318816] worker_thread+0x320/0x438[ 1457.322552] kthread+0x110/0x114[ 1457.325767] ret_from_fork+0x10/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56576 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: tc358743: Fix crash in the probe error path when using pollingIf an error occurs in the probe() function, we should remove the pollingtimer that was alarmed earlier, otherwise the timer is called witharguments that are already freed, which results in a crash.------------[ cut here ]------------WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268Modules linked in:CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226Hardware name: Diasom DS-RK3568-SOM-EVB (DT)pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __run_timers+0x244/0x268lr : __run_timers+0x1d4/0x268sp : ffffff80eff2baf0x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffffx17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003ex14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0Call trace: __run_timers+0x244/0x268 timer_expire_remote+0x50/0x68 tmigr_handle_remote+0x388/0x39c run_timer_softirq+0x38/0x44 handle_softirqs+0x138/0x298 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0x9c/0xcc el1_interrupt+0x48/0xc0 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x7c/0x80 default_idle_call+0x34/0x68 do_idle+0x23c/0x294 cpu_startup_entry+0x38/0x3c secondary_start_kernel+0x128/0x160 __secondary_switched+0xb8/0xbc---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56578 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Set video drvdata before register video deviceThe video drvdata should be set before the video device is registered,otherwise video_drvdata() may return NULL in the open() file ops, and ledto oops.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56581 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: ref-verify: fix use-after-free after invalid ref actionAt btrfs_ref_tree_mod() after we successfully inserted the new ref entry(local variable 'ref') into the respective block entry's rbtree (localvariable 'be'), if we find an unexpected action of BTRFS_DROP_DELAYED_REF,we error out and free the ref entry without removing it from the blockentry's rbtree. Then in the error path of btrfs_ref_tree_mod() we callbtrfs_free_ref_cache(), which iterates over all block entries and thencalls free_block_entry() for each one, and there we will trigger ause-after-free when we are called against the block entry to which weadded the freed ref entry to its rbtree, since the rbtree still pointsto the block entry, as we didn't remove it from the rbtree before freeingit in the error path at btrfs_ref_tree_mod(). Fix this by removing thenew ref entry from the rbtree before freeing it.Syzbot report this with the following stack traces: BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314 btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline] btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23 btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482 btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293 vfs_unlink+0x365/0x650 fs/namei.c:4469 do_unlinkat+0x4ae/0x830 fs/namei.c:4533 __do_sys_unlinkat fs/namei.c:4576 [inline] __se_sys_unlinkat fs/namei.c:4569 [inline] __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569 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 BTRFS error (device loop0 state EA): Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1 __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521 update_ref_for_cow+0x96a/0x11f0 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_i---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56583 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: Fix warning in migrate_enable for boosted tasksWhen running the following command:while true; do stress-ng --cyclic 30 --timeout 30s --minimize --quietdonea warning is eventually triggered:WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794setup_new_dl_entity+0x13e/0x180...Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? enqueue_dl_entity+0x631/0x6e0 ? setup_new_dl_entity+0x13e/0x180 ? __warn+0x7e/0xd0 ? report_bug+0x11a/0x1a0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 enqueue_dl_entity+0x631/0x6e0 enqueue_task_dl+0x7d/0x120 __do_set_cpus_allowed+0xe3/0x280 __set_cpus_allowed_ptr_locked+0x140/0x1d0 __set_cpus_allowed_ptr+0x54/0xa0 migrate_enable+0x7e/0x150 rt_spin_unlock+0x1c/0x90 group_send_sig_info+0xf7/0x1a0 ? kill_pid_info+0x1f/0x1d0 kill_pid_info+0x78/0x1d0 kill_proc_info+0x5b/0x110 __x64_sys_kill+0x93/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f0dab31f92bThis warning occurs because set_cpus_allowed dequeues and enqueues taskswith the ENQUEUE_RESTORE flag set. If the task is boosted, the warningis triggered. A boosted task already had its parameters set byrt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary,hence the WARN_ON call.Check if we are requeueing a boosted task and avoid callingsetup_new_dl_entity if that's the case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56584 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/tctx: work around xa_store() allocation error issuesyzbot triggered the following WARN_ON:WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51which is theWARN_ON_ONCE(!xa_empty(&tctx->xa));sanity check in __io_uring_free() when a io_uring_task is going throughits final put. The syzbot test case includes injecting memory allocationfailures, and it very much looks like xa_store() can fail one of itsmemory allocations and end up with ->head being non-NULL even though noentries exist in the xarray.Until this issue gets sorted out, work around it by attempting toiterate entries in our xarray, and WARN_ON_ONCE() if one is found.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56589 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Add cond_resched() for no forced preemption modelFor no forced preemption model kernel, in the scenario where theexpander is connected to 12 high performance SAS SSDs, the followingcall trace may occur:[ 214.409199][ C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisi_sa:3211][ 214.568533][ C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)[ 214.575224][ C240] pc : fput_many+0x8c/0xdc[ 214.579480][ C240] lr : fput+0x1c/0xf0[ 214.583302][ C240] sp : ffff80002de2b900[ 214.587298][ C240] x29: ffff80002de2b900 x28: ffff1082aa412000[ 214.593291][ C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000[ 214.599284][ C240] x25: ffff1062bbac5c40 x24: 0000000000001000[ 214.605277][ C240] x23: 000000000000000a x22: 0000000000000001[ 214.611270][ C240] x21: 0000000000001000 x20: 0000000000000000[ 214.617262][ C240] x19: ffff3062a41ae580 x18: 0000000000010000[ 214.623255][ C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0[ 214.629248][ C240] x15: ffffffffffffffff x14: 0000000003ffffff[ 214.635241][ C240] x13: 000000000000ffff x12: 000000000000029c[ 214.641234][ C240] x11: 0000000000000006 x10: ffff80003a9f7fd0[ 214.647226][ C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001[ 214.653219][ C240] x7 : 0000000000000002 x6 : 0000000000000080[ 214.659212][ C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554[ 214.665205][ C240] x3 : 0000000000000002 x2 : 0000000000000020[ 214.671198][ C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8[ 214.677191][ C240] Call trace:[ 214.680320][ C240] fput_many+0x8c/0xdc[ 214.684230][ C240] fput+0x1c/0xf0[ 214.687707][ C240] aio_complete_rw+0xd8/0x1fc[ 214.692225][ C240] blkdev_bio_end_io+0x98/0x140[ 214.696917][ C240] bio_endio+0x160/0x1bc[ 214.701001][ C240] blk_update_request+0x1c8/0x3bc[ 214.705867][ C240] scsi_end_request+0x3c/0x1f0[ 214.710471][ C240] scsi_io_completion+0x7c/0x1a0[ 214.715249][ C240] scsi_finish_command+0x104/0x140[ 214.720200][ C240] scsi_softirq_done+0x90/0x180[ 214.724892][ C240] blk_mq_complete_request+0x5c/0x70[ 214.730016][ C240] scsi_mq_done+0x48/0xac[ 214.734194][ C240] sas_scsi_task_done+0xbc/0x16c [libsas][ 214.739758][ C240] slot_complete_v3_hw+0x260/0x760 [hisi_sas_v3_hw][ 214.746185][ C240] cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw][ 214.752179][ C240] irq_thread_fn+0x34/0xa4[ 214.756435][ C240] irq_thread+0xc4/0x130[ 214.760520][ C240] kthread+0x108/0x13c[ 214.764430][ C240] ret_from_fork+0x10/0x18This is because in the hisi_sas driver, both the hardware interrupthandler and the interrupt thread are executed on the same CPU. In theperformance test scenario, function irq_wait_for_interrupt() will alwaysreturn 0 if lots of interrupts occurs and the CPU will be continuouslyconsumed. As a result, the CPU cannot run the watchdog thread. When thewatchdog time exceeds the specified time, call trace occurs.To fix it, add cond_resched() to execute the watchdog thread.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56592 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Call free_htab_elem() after htab_unlock_bucket()For htab of maps, when the map is removed from the htab, it may hold thelast reference of the map. bpf_map_fd_put_ptr() will invokebpf_map_free_id() to free the id of the removed map element. However,bpf_map_fd_put_ptr() is invoked while holding a bucket lock(raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock(spinlock_t), triggering the following lockdep warning: ============================= [ BUG: Invalid wait context ] 6.11.0-rc4+ #49 Not tainted ----------------------------- test_maps/4881 is trying to lock: ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70 other info that might help us debug this: context-{5:5} 2 locks held by test_maps/4881: #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270 #1: ffff888149ced148 (&htab->lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80 stack backtrace: CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ... Call Trace: dump_stack_lvl+0x6e/0xb0 dump_stack+0x10/0x20 __lock_acquire+0x73e/0x36c0 lock_acquire+0x182/0x450 _raw_spin_lock_irqsave+0x43/0x70 bpf_map_free_id.part.0+0x21/0x70 bpf_map_put+0xcf/0x110 bpf_map_fd_put_ptr+0x9a/0xb0 free_htab_elem+0x69/0xe0 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 bpf_map_update_value+0x266/0x380 __sys_bpf+0x21bb/0x36b0 __x64_sys_bpf+0x45/0x60 x64_sys_call+0x1b2a/0x20d0 do_syscall_64+0x5d/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7eOne way to fix the lockdep warning is using raw_spinlock_t formap_idr_lock as well. However, bpf_map_alloc_id() invokesidr_alloc_cyclic() after acquiring map_idr_lock, it will trigger asimilar lockdep warning because the slab's lock (s->cpu_slab->lock) isstill a spinlock.Instead of changing map_idr_lock's type, fix the issue by invokinghtab_put_fd_value() after htab_unlock_bucket(). However, only deferringthe invocation of htab_put_fd_value() is not enough, because the old mappointers in htab of maps can not be saved during batched deletion.Therefore, also defer the invocation of free_htab_elem(), so theseto-be-freed elements could be linked together similar to lru map.There are four callers for ->map_fd_put_ptr:(1) alloc_htab_elem() (through htab_put_fd_value())It invokes ->map_fd_put_ptr() under a raw_spinlock_t. The invocation ofhtab_put_fd_value() can not simply move after htab_unlock_bucket(),because the old element has already been stashed in htab->extra_elems.It may be reused immediately after htab_unlock_bucket() and theinvocation of htab_put_fd_value() after htab_unlock_bucket() may releasethe newly-added element incorrectly. Therefore, saving the map pointerof the old element for htab of maps before unlocking the bucket andreleasing the map_ptr after unlock. Beside the map pointer in the oldelement, should do the same thing for the special fields in the oldelement as well.(2) free_htab_elem() (through htab_put_fd_value())Its caller includes __htab_map_lookup_and_delete_elem(),htab_map_delete_elem() and __htab_map_lookup_and_delete_batch().For htab_map_delete_elem(), simply invoke free_htab_elem() afterhtab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), justlike lru map, linking the to-be-freed element into node_to_free listand invoking free_htab_elem() for these element after unlock. It is safeto reuse batch_flink as the link for node_to_free, because theseelements have been removed from the hash llist.Because htab of maps doesn't support lookup_and_delete operation,__htab_map_lookup_and_delete_elem() doesn't have the problem, so keptit as---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56593 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()This patch fixes a NULL pointer dereference bug in brcmfmac that occurswhen a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBsare sent from the pkt queue.The problem is the number of entries in the pre-allocated sgtable, it isnents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1.Given the default [rt]xglom_size=32 it's actually 35 which is too small.Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKBis added for each original SKB if tailroom isn't enough to hold tail_pad.At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next returnNULL and this causes the oops.The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handlethe worst-case.Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464additional bytes of memory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56594 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: set the right AMDGPU sg segment limitationThe driver needs to set the correct max_segment_size;otherwise debug_dma_map_sg() will complain about theover-mapping of the AMDGPU sg length as following:WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370[ 364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd[ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii[ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE 6.10.0-custom #492[ 364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021[ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370[ 364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05[ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286[ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027[ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680[ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930[ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000[ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800[ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000[ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0[ 364.049605] Call Trace:[ 364.049607] [ 364.049609] ? show_regs+0x6d/0x80[ 364.049614] ? __warn+0x8c/0x140[ 364.049618] ? debug_dma_map_sg+0x2dc/0x370[ 364.049621] ? report_bug+0x193/0x1a0[ 364.049627] ? handle_bug+0x46/0x80[ 364.049631] ? exc_invalid_op+0x1d/0x80[ 364.049635] ? asm_exc_invalid_op+0x1f/0x30[ 364.049642] ? debug_dma_map_sg+0x2dc/0x370[ 364.049647] __dma_map_sg_attrs+0x90/0xe0[ 364.049651] dma_map_sgtable+0x25/0x40[ 364.049654] amdgpu_bo_move+0x59a/0x850 [amdgpu][ 364.049935] ? srso_return_thunk+0x5/0x5f[ 364.049939] ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu][ 364.050095] ttm_bo_handle_move_mem+0xc3/0x180 [ttm][ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm][ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu][ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu][ 364.050473] kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu][ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu][ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu][ 364.05105---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56595 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: add a check to prevent array-index-out-of-bounds in dbAdjTreeWhen the value of lp is 0 at the beginning of the for loop, it willbecome negative in the next assignment and we should bail out.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56596 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix array-index-out-of-bounds in jfs_readdirThe stbl might contain some invalid values. Added a check toreturn error code in that case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56603 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: af_can: do not leave a dangling sk pointer in can_create()On error can_create() frees the allocated sk object, but sock_init_data()has already attached it to the provided sock object. This will leave adangling sk pointer in the sock object and may cause use-after-free later.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56606 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:af_packet: avoid erroring out after sock_init_data() in packet_create()After sock_init_data() the allocated sk object is attached to the providedsock object. On error, packet_create() frees the sk object leaving thedangling pointer in the sock object on return. Some other code may tryto use this pointer and cause use-after-free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56611 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn'ttrue.So we might end up having find_vma() return NULL, to then de-referenceNULL. So properly handle find_vma() returning NULL.This fixes the report:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f[akpm@linux-foundation.org: add unlikely()]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56614 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: fix OOB map writes when deleting elementsJordy says:"In the xsk_map_delete_elem function an unsigned integer(map->max_entries) is compared with a user-controlled signed integer(k). Due to implicit type conversion, a large unsigned value formap->max_entries can bypass the intended bounds check: if (k >= map->max_entries) return -EINVAL;This allows k to hold a negative value (between -2147483648 and -2),which is then used as an array index in m->xsk_map[k], which resultsin an out-of-bounds access. spin_lock_bh(&m->lock); map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry old_xs = unrcu_pointer(xchg(map_entry, NULL)); // Oob write if (old_xs) xsk_map_sock_delete(old_xs, map_entry); spin_unlock_bh(&m->lock);The xchg operation can then be used to cause an out-of-bounds write.Moreover, the invalid map_entry passed to xsk_map_sock_delete can leadto further memory corruption."It indeed results in following splat:[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108[76612.904330] #PF: supervisor write access in kernel mode[76612.909639] #PF: error_code(0x0002) - not-present page[76612.914855] PGD 0 P4D 0[76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP[76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470[76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60[76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31[76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246[76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000[76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000[76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007[76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8[76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0[76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000[76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0[76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[76613.041086] PKRU: 55555554[76613.043842] Call Trace:[76613.046331] [76613.048468] ? __die+0x20/0x60[76613.051581] ? page_fault_oops+0x15a/0x450[76613.055747] ? search_extable+0x22/0x30[76613.059649] ? search_bpf_extables+0x5f/0x80[76613.063988] ? exc_page_fault+0xa9/0x140[76613.067975] ? asm_exc_page_fault+0x22/0x30[76613.072229] ? xsk_map_delete_elem+0x2d/0x60[76613.076573] ? xsk_map_delete_elem+0x23/0x60[76613.080914] __sys_bpf+0x19b7/0x23c0[76613.084555] __x64_sys_bpf+0x1a/0x20[76613.088194] do_syscall_64+0x37/0xb0[76613.091832] entry_SYSCALL_64_after_hwframe+0x4b/0x53[76613.096962] RIP: 0033:0x7f80b6d1e88d[76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48[76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141[76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d[76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003[76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000[76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8[76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56615 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix OOB devmap writes when deleting elementsJordy reported issue against XSKMAP which also applies to DEVMAP - theindex used for accessing map entry, due to being a signed integer,causes the OOB writes. Fix is simple as changing the type from int tou32, however, when compared to XSKMAP case, one more thing needs to beaddressed.When map is released from system via dev_map_free(), we iterate throughall of the entries and an iterator variable is also an int, whichimplies OOB accesses. Again, change it to be u32.Example splat below:[ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000[ 160.731662] #PF: supervisor read access in kernel mode[ 160.736876] #PF: error_code(0x0000) - not-present page[ 160.742095] PGD 0 P4D 0[ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP[ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487[ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[ 160.767642] Workqueue: events_unbound bpf_map_free_deferred[ 160.773308] RIP: 0010:dev_map_free+0x77/0x170[ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff[ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202[ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024[ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000[ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001[ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122[ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000[ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000[ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0[ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 160.874092] PKRU: 55555554[ 160.876847] Call Trace:[ 160.879338] [ 160.881477] ? __die+0x20/0x60[ 160.884586] ? page_fault_oops+0x15a/0x450[ 160.888746] ? search_extable+0x22/0x30[ 160.892647] ? search_bpf_extables+0x5f/0x80[ 160.896988] ? exc_page_fault+0xa9/0x140[ 160.900973] ? asm_exc_page_fault+0x22/0x30[ 160.905232] ? dev_map_free+0x77/0x170[ 160.909043] ? dev_map_free+0x58/0x170[ 160.912857] bpf_map_free_deferred+0x51/0x90[ 160.917196] process_one_work+0x142/0x370[ 160.921272] worker_thread+0x29e/0x3b0[ 160.925082] ? rescuer_thread+0x4b0/0x4b0[ 160.929157] kthread+0xd4/0x110[ 160.932355] ? kthread_park+0x80/0x80[ 160.936079] ret_from_fork+0x2d/0x50[ 160.943396] ? kthread_park+0x80/0x80[ 160.950803] ret_from_fork_asm+0x11/0x20[ 160.958482]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56616 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type 'u8 [48]' Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field "&msg->msg[msg->curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56622 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: sysfs: Prevent div by zeroPrevent a division by 0 when monitoring is not enabled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56629 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: wacom: fix when get product name maybe null pointerDue to incorrect dev->product reporting by certain devices, nullpointer dereferences occur when dev->product is empty, leading topotential system crashes.This issue was found on EXCELSIOR DL37-D05 device withLoongson-LS3A6000-7A2000-DL37 motherboard.Kernel logs:[ 56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci[ 56.671638] usb 4-3: string descriptor 0 read error: -22[ 56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07[ 56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3[ 56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0[ 56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80[ 56.697732] Oops[#1]:[ 56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G OE 6.6.0-loong64-desktop #25.00.2000.015[ 56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024[ 56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0[ 56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000[ 56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000[ 56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005[ 56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000[ 56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028[ 56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000[ 56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000[ 56.697753] ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom][ 56.697802] ERA: 90000000066e35c8 strstr+0x28/0x120[ 56.697806] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)[ 56.697816] PRMD: 0000000c (PPLV0 +PIE +PWE)[ 56.697821] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)[ 56.697827] ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)[ 56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)[ 56.697835] BADV: 0000000000000000[ 56.697836] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)[ 56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit[ 56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3)[ 56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000[ 56.697896] 0000000000000000 00000011fffffffd 0000000000000000 0000000000000000[ 56.697901] 0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0[ 56.697906] 90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c[ 56.697911] 90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440[ 56.697916] ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0[ 56.697921] 0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c[ 56.697926] ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000[ 56.697931] 90000001000bb8d0 ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56630 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: free inode when ocfs2_get_init_inode() failssyzbot is reporting busy inodes after unmount, for commit 9c89fe0af826("ocfs2: Handle error from dquot_initialize()") forgot to call iput() whennew_inode() succeeded and dquot_initialize() failed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56633 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsgThe current sk memory accounting logic in __SK_REDIRECT is pre-unchargingtosend bytes, which is either msg->sg.size or a smaller value apply_bytes.Potential problems with this strategy are as follows:- If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean.- When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - apply_bytes) bytes.[...]415 tosend = msg->sg.size;416 if (psock->apply_bytes && psock->apply_bytes < tosend)417 tosend = psock->apply_bytes;[...]443 sk_msg_return(sk, msg, tosend);444 release_sock(sk);446 origsize = msg->sg.size;447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,448 msg, tosend, flags);449 sent = origsize - msg->sg.size;[...]454 lock_sock(sk);455 if (unlikely(ret < 0)) {456 int free = sk_msg_free_nocharge(sk, msg);458 if (!cork)459 *copied -= free;460 }[...]487 if (eval == __SK_REDIRECT)488 sk_mem_charge(sk, tosend - sent);[...]When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,the following warning will be reported:------------[ cut here ]------------WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0Modules linked in:CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014Workqueue: events sk_psock_destroyRIP: 0010:inet_sock_destruct+0x190/0x1a0RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace:? __warn+0x89/0x130? inet_sock_destruct+0x190/0x1a0? report_bug+0xfc/0x1e0? handle_bug+0x5c/0xa0? exc_invalid_op+0x17/0x70? asm_exc_invalid_op+0x1a/0x20? inet_sock_destruct+0x190/0x1a0__sk_destruct+0x25/0x220sk_psock_destroy+0x2b2/0x310process_scheduled_works+0xa3/0x3e0worker_thread+0x117/0x240? __pfx_worker_thread+0x10/0x10kthread+0xcf/0x100? __pfx_kthread+0x10/0x10ret_from_fork+0x31/0x40? __pfx_kthread+0x10/0x10ret_from_fork_asm+0x1a/0x30---[ end trace 0000000000000000 ]---In __SK_REDIRECT, a more concise way is delaying the uncharging after sentbytes are finalized, and uncharge this value. When (ret < 0), we shallinvoke sk_msg_free.Same thing happens in case __SK_DROP, when tosend is set to apply_bytes,we may miss uncharging (msg->sg.size - apply_bytes) bytes. The samewarning will be reported in selftest.[...]468 case __SK_DROP:469 default:470 sk_msg_free_partial(sk, msg, tosend);471 sk_msg_apply_bytes(psock, tosend);472 *copied -= (tosend + delta);473 return -EACCES;[...]So instead of sk_msg_free_partial we can do sk_msg_free here.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56634 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: grgpio: Add NULL check in grgpio_probedevm_kasprintf() can return a NULL pointer on failure,but thisreturned value in grgpio_probe is not checked.Add NULL check in grgpio_probe, to handle kernel NULLpointer dereference error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56640 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix LGR and link use-after-free issueWe encountered a LGR/link use-after-free issue, which manifested asthe LGR/link refcnt reaching 0 early and entering the clear process,making resource access unsafe. refcount_t: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140 Workqueue: events smc_lgr_terminate_work [smc] Call trace: refcount_warn_saturate+0x9c/0x140 __smc_lgr_terminate.part.45+0x2a8/0x370 [smc] smc_lgr_terminate_work+0x28/0x30 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118or refcount_t: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140 Workqueue: smc_hs_wq smc_listen_work [smc] Call trace: refcount_warn_saturate+0xf0/0x140 smcr_link_put+0x1cc/0x1d8 [smc] smc_conn_free+0x110/0x1b0 [smc] smc_conn_abort+0x50/0x60 [smc] smc_listen_find_device+0x75c/0x790 [smc] smc_listen_work+0x368/0x8a0 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118It is caused by repeated release of LGR/link refcnt. One suspect is thatsmc_conn_free() is called repeatedly because some smc_conn_free() fromserver listening path are not protected by sock lock.e.g.Calls under socklock | smc_listen_work-------------------------------------------------------lock_sock(sk) | smc_conn_abortsmc_conn_free | \- smc_conn_free\- smcr_link_put | \- smcr_link_put (duplicated)release_sock(sk)So here add sock lock protection in smc_listen_work() path, making itexclusive with other connection operations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56641 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: initialize close_work early to avoid warningWe encountered a warning that close_work was canceled beforeinitialization. WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: events smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Call Trace: ? __wake_up_common+0x7a/0x190 ? work_busy+0x80/0x80 __cancel_work_timer+0xe3/0x160 smc_close_cancel_work+0x1a/0x70 [smc] smc_close_active_abort+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] process_one_work+0x19e/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30This is because when smc_close_cancel_work is triggered, e.g. the RDMAdriver is rmmod and the LGR is terminated, the conn->close_work isflushed before initialization, resulting in WARN_ON(!work->func).__smc_lgr_terminate | smc_connect_{rdma|ism}------------------------------------------------------------- | smc_conn_create | \- smc_lgr_register_connfor conn in lgr->conns_all |\- smc_conn_kill | \- smc_close_active_abort | \- smc_close_cancel_work | \- cancel_work_sync | \- __flush_work | (close_work) | | smc_close_init | \- INIT_WORK(&close_work)So fix this by initializing close_work before establishing theconnection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56647 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix icmp host relookup triggering ip_rt_bugarp link failure may trigger ip_rt_bug while xfrm enabled, call trace is:WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20Modules linked in:CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:ip_rt_bug+0x14/0x20Call Trace: ip_send_skb+0x14/0x40 __icmp_send+0x42d/0x6a0 ipv4_link_failure+0xe2/0x1d0 arp_error_report+0x3c/0x50 neigh_invalidate+0x8d/0x100 neigh_timer_handler+0x2e1/0x330 call_timer_fn+0x21/0x120 __run_timer_base.part.0+0x1c9/0x270 run_timer_softirq+0x4c/0x80 handle_softirqs+0xac/0x280 irq_exit_rcu+0x62/0x80 sysvec_apic_timer_interrupt+0x77/0x90The script below reproduces this scenario:ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmpip l a veth1 type vethip a a 192.168.141.111/24 dev veth0ip l s veth0 upping 192.168.141.155 -c 1icmp_route_lookup() create input routes for locally generated packetswhile xfrm relookup ICMP traffic.Then it will set input route(dst->out = ip_rt_bug) to skb for DESTUNREACH.For ICMP err triggered by locally generated packets, dst->dev of outputroute is loopback. Generally, xfrm relookup verification is not requiredon loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).Skip icmp relookup for locally generated packets to fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56657 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: control: Avoid WARN() for symlink errorsUsing WARN() for showing the error of symlink creations don't givemore information than telling that something goes wrong, since theusual code path is a lregister callback from each control elementcreation. More badly, the use of WARN() rather confuses fuzzer as ifit were serious issues.This patch downgrades the warning messages to use the normal dev_err()instead of WARN(). For making it clearer, add the function name tothe prefix, too.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56659 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: lapb: increase LAPB_HEADER_LENIt is unclear if net/lapb code is supposed to be ready for 8021q.We can at least avoid crashes like the following :skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016FS: 00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 nr_header+0x36/0x320 net/netrom/nr_dev.c:69 dev_hard_header include/linux/netdevice.h:3148 [inline] vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83 dev_hard_header include/linux/netdevice.h:3148 [inline] lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149 lapb_establish_data_link+0x84/0xd0 lapb_device_event+0x4e0/0x670 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922 devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188 inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x158/0x460 net/socket.c:1227 sock_ioctl+0x626/0x8e0 net/socket.c:1346 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56660 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: DR, prevent potential error pointer dereferenceThe dr_domain_add_vport_cap() function generally returns NULL on errorbut sometimes we want it to return ERR_PTR(-EBUSY) so the caller canretry. The problem here is that "ret" can be either -EBUSY or -ENOMEMand if it's and -ENOMEM then the error pointer is propogated back andeventually dereferenced in dr_ste_v0_build_src_gvmi_qpn_tag().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56679 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.cAdd error pointer check after calling otx2_mbox_get_rsp().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56688 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transportSince transport->sock has been set to NULL during reset transport,XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, thexs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()to dereference the transport->sock that has been set to NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56691 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C deviceWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56698 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: gadget: Fix looping of queued SG entriesThe dwc3_request->num_queued_sgs is decremented on completion. If apartially completed request is handled, then thedwc3_request->num_queued_sgs no longer reflects the total number ofnum_queued_sgs (it would be cleared).Correctly check the number of request SG entries remained to be prepareand queued. Failure to do this may cause null pointer dereference whenaccessing non-existent SG entry.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56701 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: Fix dtl_access_lock to be a rw_semaphoreThe dtl_access_lock needs to be a rw_sempahore, a sleeping lock, becausethe code calls kmalloc() while holding it, which can sleep: # echo 1 > /proc/powerpc/vcpudispatch_stats BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh preempt_count: 1, expected: 0 3 locks held by sh/199: #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438 #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4 #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4 CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries Call Trace: dump_stack_lvl+0x130/0x148 (unreliable) __might_resched+0x174/0x410 kmem_cache_alloc_noprof+0x340/0x3d0 alloc_dtl_buffers+0x124/0x1ac vcpudispatch_stats_write+0x2a8/0x5f4 proc_reg_write+0xf4/0x150 vfs_write+0xfc/0x438 ksys_write+0x88/0x148 system_call_exception+0x1c4/0x5a0 system_call_common+0xf4/0x258

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56707 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.cAdd error pointer checks after calling otx2_mbox_get_rsp().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56709 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: check if iowq is killed before queuingtask work can be executed after the task has gone through io_uringtermination, whether it's the final task_work run or the fallback path.In this case, task work will find ->io_wq being already killed andnull'ed, which is a problem if it then tries to forward the request toio_queue_iowq(). Make io_queue_iowq() fail requests in this case.Note that it also checks PF_KTHREAD, because the user can first closea DEFER_TASKRUN ring and shortly after kill the task, in which case->iowq check would race.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56715 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ionic: Fix netdev notifier unregister on failureIf register_netdev() fails, then the driver leaks the netdev notifier.Fix this by calling ionic_lif_unregister() on register_netdev()failure. This will also call ionic_lif_unregister_phc() if it hasalready been registered.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56716 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: prevent bad user input in nsim_dev_health_break_write()If either a zero count or a large one is provided, kernel can crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56720 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Several fixes to bpf_msg_pop_dataSeveral fixes to bpf_msg_pop_data,1. In sk_msg_shift_left, we should put_page2. if (len == 0), return early is better3. pop the entire sk_msg (last == msg->sg.size) should be supported4. Fix for the value of variable "a"5. In sk_msg_shift_left, after shifting, i has already pointed to the nextelement. Addtional sk_msg_iter_var_next may result in BUG.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56722 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix cpu stuck caused by printings during resetDuring reset, cmd to destroy resources such as qp, cq, and mr may fail,and error logs will be printed. When a large number of resources aredestroyed, there will be lots of printings, and it may lead to a cpustuck.Delete some unnecessary printings and replace other printing functionsin these paths with the ratelimited version.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56723 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devicesWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56724 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU deviceWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56726 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.cAdd error pointer check after calling otx2_mbox_get_rsp().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56727 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.cAdding error pointer check after calling otx2_mbox_get_rsp().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56728 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.cAdd error pointer check after calling otx2_mbox_get_rsp().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56739 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rtc: check if __rtc_read_time was successful in rtc_timer_do_work()If the __rtc_read_time call fails,, the struct rtc_time tm; may containuninitialized data, or an illegal date/time read from the RTC hardware.When calling rtc_tm_to_ktime later, the result may be a very large value(possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue,they will continually expire, may causing kernel softlockup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56745 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Fix reset_method_store() memory leakIn reset_method_store(), a string is allocated via kstrndup() and assignedto the local "options". options is then used in with strsep() to findspaces: while ((name = strsep(&options, " ")) != NULL) {If there are no remaining spaces, then options is set to NULL by strsep(),so the subsequent kfree(options) doesn't free the memory allocated viakstrndup().Fix by using a separate tmp_options to iterate with strsep() so options ispreserved.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56748 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMAmemory sb_virt when it fails. Add dma_free_coherent() to free it. Thisis the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56763 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Prevent bad count for tracing_cpumask_writeIf a large count is provided, it will trigger a warning in bitmap_parse_user.Also check zero for it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56774 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: add a sanity check for btrfs root in btrfs_search_slot()Syzbot reports a null-ptr-deref in btrfs_search_slot().The reproducer is using rescue=ibadroots, and the extent tree root iscorrupted thus the extent tree is NULL.When scrub tries to search the extent tree to gather the needed extentinfo, btrfs_search_slot() doesn't check if the target root is NULL ornot, resulting the null-ptr-deref.Add sanity check for btrfs root before using it in btrfs_search_slot().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56776 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sti: avoid potential dereference of error pointersThe return value of drm_atomic_get_crtc_state() needs to bechecked. To avoid use of error pointer 'crtc_state' in caseof the failure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56777 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sti: avoid potential dereference of error pointers in sti_gdp_atomic_checkThe return value of drm_atomic_get_crtc_state() needs to bechecked. To avoid use of error pointer 'crtc_state' in caseof the failure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56778 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_checkThe return value of drm_atomic_get_crtc_state() needs to bechecked. To avoid use of error pointer 'crtc_state' in caseof the failure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56779 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occurThe action force umount(umount -f) will attempt to kill all rpc_task evenumount operation may ultimately fail if some files remain open.Consequently, if an action attempts to open a file, it can potentiallysend two rpc_task to nfs server. NFS CLIENTthread1 thread2open("file")...nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task /* rpc_task1 */ rpc_run_task rpc_wait_for_completion_task umount -f nfs_umount_begin rpc_killall_tasks rpc_signal_task rpc_task1 been wakeup and return -512 _nfs4_do_open // while loop ... nfs4_run_open_task /* rpc_task2 */ rpc_run_task rpc_wait_for_completion_taskWhile processing an open request, nfsd will first attempt to find orallocate an nfs4_openowner. If it finds an nfs4_openowner that is notmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Sincetwo rpc_task can attempt to open the same file simultaneously from theclient to server, and because two instances of nfsd can runconcurrently, this situation can lead to lots of memory leak.Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will betriggered. NFS SERVERnfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threadsnfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2 nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!! nfsd4_process_open2 ... write_threads ... nfsd_destroy_serv nfsd_shutdown_net nfs4_state_shutdown_net nfs4_state_destroy_net destroy_client __destroy_client // won't find oo1!!! nfsd_shutdown_generic nfsd_file_cache_shutdown kmem_cache_destroy for nfsd_file_slab and nfsd_file_mark_slab // bark since nfsd_file1 // and nfsd_file_mark1 // still alive=======================================================================BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on__kmem_cache_shutdown()-----------------------------------------------------------------------Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014Call Trace: dum---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-56787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: imx8m: Probe the SoC driver as platform driverWith driver_async_probe=* on kernel command line, the following trace isproduced because on i.MX8M Plus hardware because the soc-imx8m.c drivercalls of_clk_get_by_name() which returns -EPROBE_DEFER because the clockdriver is not yet probed. This was not detected during regular testingwithout driver_async_probe.Convert the SoC code to platform driver and instantiate a platform devicein its current device_initcall() to probe the platform driver. Rework.soc_revision callback to always return valid error code and return SoCrevision via parameter. This way, if anything in the .soc_revision callbackreturn -EPROBE_DEFER, it gets propagated to .probe and the .probe will getretried later."------------[ cut here ]------------WARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603Hardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT)pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : imx8mm_soc_revision+0xdc/0x180lr : imx8mm_soc_revision+0xd0/0x180sp : ffff8000821fbcc0x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfbx20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffffx17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8x14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801x11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95cx8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3x5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfbCall trace: imx8mm_soc_revision+0xdc/0x180 imx8_soc_init+0xb0/0x1e0 do_one_initcall+0x94/0x1a8 kernel_init_freeable+0x240/0x2a8 kernel_init+0x28/0x140 ret_from_fork+0x10/0x20---[ end trace 0000000000000000 ]---SoC: i.MX8MP revision 1.1"

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57807 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: megaraid_sas: Fix for a potential deadlockThis fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex);Fix this by temporarily releasing the reset_mutex.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57809 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: imx6: Fix suspend/resume support on i.MX6QDLThe suspend/resume functionality is currently broken on the i.MX6QDLplatform, as documented in the NXP errata (ERR005723): https://www.nxp.com/docs/en/errata/IMX6DQCE.pdfThis patch addresses the issue by sharing most of the suspend/resumesequences used by other i.MX devices, while avoiding modifications tocritical registers that disrupt the PCIe functionality. It targets thesame problem as the following downstream commit: https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995Unlike the downstream commit, this patch also resets the connected PCIedevice if possible. Without this reset, certain drivers, such as ath10kor iwlwifi, will crash on resume. The device reset is also done by thedriver on other i.MX platforms, making this patch consistent withexisting practices.Upon resuming, the kernel will hang and display an error. Here's anexample of the error encountered with the ath10k driver: ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible Unhandled fault: imprecise external abort (0x1406) at 0x0106f944Without this patch, suspend/resume will fail on i.MX6QDL devices if aPCIe device is connected.[kwilczynski: commit log, added tag for stable releases]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57834 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_threadsyzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]If dvb->mux is not initialized successfully by vidtv_mux_init() in thevidtv_start_streaming(), it will trigger null pointer dereference about muxin vidtv_mux_stop_thread().Adjust the timing of streaming initialization and check it beforestopping it.[1]KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 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+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 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+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57884 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()The task sometimes continues looping in throttle_direct_reclaim() becauseallow_direct_reclaim(pgdat) keeps returning false. #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974 #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4At this point, the pgdat contains the following two zones: NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32" SIZE: 20480 MIN/LOW/HIGH: 11/28/45 VM_STAT: NR_FREE_PAGES: 359 NR_ZONE_INACTIVE_ANON: 18813 NR_ZONE_ACTIVE_ANON: 0 NR_ZONE_INACTIVE_FILE: 50 NR_ZONE_ACTIVE_FILE: 0 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal" SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264 VM_STAT: NR_FREE_PAGES: 146 NR_ZONE_INACTIVE_ANON: 94668 NR_ZONE_ACTIVE_ANON: 3 NR_ZONE_INACTIVE_FILE: 735 NR_ZONE_ACTIVE_FILE: 78 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0In allow_direct_reclaim(), while processing ZONE_DMA32, the sum ofinactive/active file-backed pages calculated in zone_reclaimable_pages()based on the result of zone_page_state_snapshot() is zero. Additionally, since this system lacks swap, the calculation of inactive/active anonymous pages is skipped. crash> p nr_swap_pages nr_swap_pages = $1937 = { counter = 0 }As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on tothe processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 havingfree pages significantly exceeding the high watermark.The problem is that the pgdat->kswapd_failures hasn't been incremented. crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures $1935 = 0x0This is because the node deemed balanced. The node balancing logic inbalance_pgdat() evaluates all zones collectively. If one or more zones(e.g., ZONE_DMA32) have enough free pages to meet their watermarks, theentire node is deemed balanced. This causes balance_pgdat() to exit earlybefore incrementing the kswapd_failures, as it considers the overallmemory state acceptable, even though some zones (like ZONE_NORMAL) remainunder significant pressure.The patch ensures that zone_reclaimable_pages() includes free pages(NR_FREE_PAGES) in its calculation when no other reclaimable pages areavailable (e.g., file-backed or anonymous pages). This change preventszones like ZONE_DMA32, which have sufficient free pages, from beingmistakenly deemed unreclaimable. By doing so, the patch ensures propernode balancing, avoids masking pressure on other zones like ZONE_NORMAL,and prevents infinite loops in throttle_direct_reclaim() caused byallow_direct_reclaim(pgdat) repeatedly returning false.The kernel hangs due to a task stuck in throttle_direct_reclaim(), causedby a node being incorrectly deemed balanced despite pressure in certainzones, such as ZONE_NORMAL. This issue arises fromzone_reclaimable_pages---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57888 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM workerAfter commit746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")amdgpu started seeing the following warning: [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu]... [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]... [ ] Call Trace: [ ] ... [ ] ? check_flush_dependency+0xf5/0x110... [ ] cancel_delayed_work_sync+0x6e/0x80 [ ] amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu] [ ] amdgpu_ring_alloc+0x40/0x50 [amdgpu] [ ] amdgpu_ib_schedule+0xf4/0x810 [amdgpu] [ ] ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched] [ ] amdgpu_job_run+0xaa/0x1f0 [amdgpu] [ ] drm_sched_run_job_work+0x257/0x430 [gpu_sched] [ ] process_one_work+0x217/0x720... [ ] The intent of the verifcation done in check_flush_depedency is to ensureforward progress during memory reclaim, by flagging cases when either amemory reclaim process, or a memory reclaim work item is flushed from acontext not marked as memory reclaim safe.This is correct when flushing, but when called from thecancel(_delayed)_work_sync() paths it is a false positive because work iseither already running, or will not be running at all. Thereforecancelling it is safe and we can relax the warning criteria by letting thehelper know of the calling context.References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57889 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap lockingIf a device uses MCP23xxx IO expander to receive IRQs, the followingbug can happen: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ... preempt_count: 1, expected: 0 ... Call Trace: ... __might_resched+0x104/0x10e __might_sleep+0x3e/0x62 mutex_lock+0x20/0x4c regmap_lock_mutex+0x10/0x18 regmap_update_bits_base+0x2c/0x66 mcp23s08_irq_set_type+0x1ae/0x1d6 __irq_set_trigger+0x56/0x172 __setup_irq+0x1e6/0x646 request_threaded_irq+0xb6/0x160 ...We observed the problem while experimenting with a touchscreen driver whichused MCP23017 IO expander (I2C).The regmap in the pinctrl-mcp23s08 driver uses a mutex for protection fromconcurrent accesses, which is the default for regmaps without .fast_io,.disable_locking, etc.mcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latterlocks the mutex.However, __setup_irq() locks desc->lock spinlock before calling thesefunctions. As a result, the system tries to lock the mutex whole holdingthe spinlock.It seems, the internal regmap locks are not needed in this driver at all.mcp->lock seems to protect the regmap from concurrent accesses already,except, probably, in mcp_pinconf_get/set.mcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called underchip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takesmcp->lock and enables regmap caching, so that the potentially slow I2Caccesses are deferred until chip_bus_unlock().The accesses to the regmap from mcp23s08_probe_one() do not need additionallocking.In all remaining places where the regmap is accessed, exceptmcp_pinconf_get/set(), the driver already takes mcp->lock.This patch adds locking in mcp_pinconf_get/set() and disables internallocking in the regmap config. Among other things, it fixes the sleepingin atomic context described above.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57892 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix slab-use-after-free due to dangling pointer dqi_privWhen mounting ocfs2 and then remounting it as read-only, aslab-use-after-free occurs after the user uses a syscall toquota_getnextquota. Specifically, sb_dqinfo(sb, type)->dqi_priv is thedangling pointer.During the remounting process, the pointer dqi_priv is freed but is neverset as null leaving it to be accessed. Additionally, the read-only optionfor remounting sets the DQUOT_SUSPENDED flag instead of setting theDQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting thenext quota, the function ocfs2_get_next_id is called and only checks thequota usage flags and not the quota suspended flags.To fix this, I set dqi_priv to null when it is freed after remounting withread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.[akpm@linux-foundation.org: coding-style cleanups]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57896 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: flush delalloc workers queue before stopping cleaner kthread during unmountDuring the unmount path, at close_ctree(), we first stop the cleanerkthread, using kthread_stop() which frees the associated task_struct, andthen stop and destroy all the work queues. However after we stopped thecleaner we may still have a worker from the delalloc_workers queue runninginode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(),which in turn tries to wake up the cleaner kthread - which was alreadydestroyed before, resulting in a use-after-free on the task_struct.Syzbot reported this with the following stack traces: BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-delalloc btrfs_work_helper Call 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_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205 submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615 run_ordered_work fs/btrfs/async-thread.c:288 [inline] btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:250 [inline] slab_post_alloc_hook mm/slub.c:4104 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1113 copy_process+0x5d1/0x3d50 kernel/fork.c:2225 kernel_clone+0x223/0x870 kernel/fork.c:2807 kernel_thread+0x1bc/0x240 kernel/fork.c:2869 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:767 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 24: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2338 [inline] slab_free mm/slub.c:4598 [inline] kmem_cache_free+0x195/0x410 mm/slub.c:4700 put_task_struct include/linux/sched/task.h:144 [inline] delayed_put_task_struct+0x125/0x300 kernel/exit.c:227 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:943 ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57903 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: restrict SO_REUSEPORT to inet socketsAfter blamed commit, crypto sockets could accidentally be destroyedfrom RCU call back, as spotted by zyzbot [1].Trying to acquire a mutex in RCU callback is not allowed.Restrict SO_REUSEPORT socket option to inet sockets.v1 of this patch supported TCP, UDP and SCTP sockets,but fcnal-test.sh test needed RAW and ICMP support.[1]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:562in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1preempt_count: 100, expected: 0RCU nest depth: 0, expected: 01 lock held by ksoftirqd/1/24: #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823Preemption disabled at: [] softirq_handle_begin kernel/softirq.c:402 [inline] [] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #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 __might_resched+0x5d4/0x780 kernel/sched/core.c:8758 __mutex_lock_common kernel/locking/mutex.c:562 [inline] __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735 crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179 aead_release+0x3d/0x50 crypto/algif_aead.c:489 alg_do_release crypto/af_alg.c:118 [inline] alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502 __sk_destruct+0x58/0x5f0 net/core/sock.c:2260 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 run_ksoftirqd+0xca/0x130 kernel/softirq.c:950 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add check for granularity in dml ceil/floor helpers[Why]Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2()should check for granularity is non zero to avoid assert anddivide-by-zero error in dcn_bw_ functions.[How]Add check for granularity 0.(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57924 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs: relax assertions on failure to encode file handlesEncoding file handles is usually performed by a filesystem >encode_fh()method that may fail for various reasons.The legacy users of exportfs_encode_fh(), namely, nfsd andname_to_handle_at(2) syscall are ready to cope with the possibilityof failure to encode a file handle.There are a few other users of exportfs_encode_{fh,fid}() thatcurrently have a WARN_ON() assertion when ->encode_fh() fails.Relax those assertions because they are wrong.The second linked bug report states commit 16aac5ad1fa9 ("ovl: supportencoding non-decodable file handles") in v6.6 as the regressing commit,but this is not accurate.The aforementioned commit only increases the chances of the assertionand allows triggering the assertion with the reproducer using overlayfs,inotify and drop_caches.Triggering this assertion was always possible with other filesystems andother reasons of ->encode_fh() failures and more particularly, it wasalso possible with the exact same reproducer using overlayfs that ismounted with options index=on,nfs_export=on also on kernels < v6.6.Therefore, I am not listing the aforementioned commit as a Fixes commit.Backport hint: this patch will have a trivial conflict applying tov6.6.y, and other trivial conflicts applying to stable kernels < v6.6.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57932 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: guard XDP xmit NDO on existence of xdp queuesIn GVE, dedicated XDP queues only exist when an XDP program is installedand the interface is up. As such, the NDO XDP XMIT callback shouldreturn early if either of these conditions are false.In the case of no loaded XDP program, priv->num_xdp_queues=0 which cancause a divide-by-zero error, and in the case of interface down,num_xdp_queues remains untouched to persist XDP queue count for the nextinterface up, but the TX pointer itself would be NULL.The XDP xmit callback also needs to synchronize with a devicetransitioning from open to close. This synchronization will happen viathe GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call,which waits for any RCU critical sections at call-time to complete.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57933 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: guard XSK operations on the existence of queuesThis patch predicates the enabling and disabling of XSK pools on theexistence of queues. As it stands, if the interface is down, disablingor enabling XSK pools would result in a crash, as the RX queue pointerwould be NULL. XSK pool registration will occur as part of the nextinterface up.Similarly, xsk_wakeup needs be guarded against queues disappearingwhile the function is executing, so a check against theGVE_PRIV_FLAGS_NAPI_ENABLED flag is added to synchronize with thedisabling of the bit and the synchronize_net() in gve_turndown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57938 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sctp: Prevent autoclose integer overflow in sctp_association_init()While by default max_autoclose equals to INT_MAX / HZ, one may setnet.sctp.max_autoclose to UINT_MAX. There is code insctp_association_init() that can consequently trigger overflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57973 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rdma/cxgb4: Prevent potential integer overflow on 32bitThe "gl->tot_len" variable is controlled by the user. It comes fromprocess_responses(). On 32bit systems, the "gl->tot_len + sizeof(structcpl_pass_accept_req) + sizeof(struct rss_header)" addition could have aninteger wrapping bug. Use size_add() to prevent this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57974 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udp: Deal with race between UDP socket address change and rehashIf a UDP socket changes its local address while it's receivingdatagrams, as a result of connect(), there is a period during whicha lookup operation might fail to find it, after the address is changedbut before the secondary hash (port and address) and the four-tuplehash (local and remote ports and addresses) are updated.Secondary hash chains were introduced by commit 30fff9231fad ("udp:bind() optimisation") and, as a result, a rehash operation becameneeded to make a bound socket reachable again after a connect().This operation was introduced by commit 719f835853a9 ("udp: addrehash on connect()") which isn't however a complete fix: thesocket will be found once the rehashing completes, but not whileit's pending.This is noticeable with a socat(1) server in UDP4-LISTEN mode, and aclient sending datagrams to it. After the server receives the firstdatagram (cf. _xioopen_ipdgram_listen()), it issues a connect() tothe address of the sender, in order to set up a directed flow.Now, if the client, running on a different CPU thread, happens tosend a (subsequent) datagram while the server's socket changes itsaddress, but is not rehashed yet, this will result in a failedlookup and a port unreachable error delivered to the client, asapparent from the following reproducer: LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4)) dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in while :; do taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.1 || sleep 1 taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null wait donewhere the client will eventually get ECONNREFUSED on a write()(typically the second or third one of a given iteration): 2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refusedThis issue was first observed as a seldom failure in Podman's testschecking UDP functionality while using pasta(1) to connect thecontainer's network namespace, which leads us to a reproducer withthe lookup error resulting in an ICMP packet on a tap device: LOCAL_ADDR="$(ip -j -4 addr show|jq -rM '.[] | .addr_info[0] | select(.scope == "global").local')" while :; do ./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.2 || sleep 1 socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null wait cmp tmp.in tmp.out doneOnce this fails: tmp.in tmp.out differ: char 8193, line 29we can finally have a look at what's going on: $ tshark -r pasta.pcap 1 0.000000 :: ? ff02::16 ICMPv6 110 Multicast Listener Report Message v2 2 0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 3 0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 4 0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 5 0.168827 c6:47:05:8d:dc:04 ? Broadcast ARP 42 Who has 88.198.0.161? Tell 88.198.0.164 6 0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55 7 0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 8 0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable) 9 0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 10 0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 11 0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096 12 0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0On the third datagram received, the network namespace of the containerinitiates an ARP lookup to deliver the ICMP message.In another variant of this reproducer, starting the client with: strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,tru---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57979 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pps: Fix a use-after-freeOn a board running ntpd and gpsd, I'm seeing a consistent use-after-freein sys_exit() from gpsd when rebooting: pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]---...followed by more symptoms of corruption, with similar stacks: refcount_t: underflow; use-after-free. kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exceptionThis happens because pps_device_destruct() frees the pps_device with theembedded cdev immediately after calling cdev_del(), but, as the commentabove cdev_del() notes, fops for previously opened cdevs are stillcallable even after cdev_del() returns. I think this bug has alwaysbeen there: I can't explain why it suddenly started happening every timeI reboot this particular board.In commit d953e0e837e6 ("pps: Fix a use-after free bug whenunregistering a source."), George Spelvin suggested removing theembedded cdev. That seems like the simplest way to fix this, so I'veimplemented his suggestion, using __register_chrdev() with pps_idrbecoming the source of truth for which minor corresponds to whichdevice.But now that pps_idr defines userspace visibility instead of cdev_add(),we need to be sure the pps->dev refcount can't reach zero whileuserspace can still find it again. So, the idr_remove() call moves topps_unregister_cdev(), and pps_idr now holds a reference to pps->dev. pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57980 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix double free in error pathIf the uvc_status_init() function fails to allocate the int_urb, it willfree the dev->status pointer but doesn't reset the pointer to NULL. Thisresults in the kfree() call in uvc_status_cleanup() trying todouble-free the memory. Fix it by resetting the dev->status pointer toNULL after freeing it.Reviewed by: Ricardo Ribalda

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57981 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Fix NULL pointer dereference on certain command abortsIf a command is queued to the final usable TRB of a ring segment, theenqueue pointer is advanced to the subsequent link TRB and no further.If the command is later aborted, when the abort completion is handledthe dequeue pointer is advanced to the first TRB of the next segment.If no further commands are queued, xhci_handle_stopped_cmd_ring() seesthe ring pointers unequal and assumes that there is a pending command,so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbellring likely is unnecessary too, but it's harmless. Leave it alone.This is probably Bug 219532, but no confirmation has been received.The issue has been independently reproduced and confirmed fixed usinga USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.Everything continued working normally after several prevented crashes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: fix out-of-bounds read during lookuplookup and resize can run in parallel.The xfrm_state_hash_generation seqlock ensures a retry, but the hashfunctions can observe a hmask value that is too large for the new hlistarray.rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask;While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {This is only safe in case the update to state_bydst is larger thannet->xfrm.xfrm_state_hmask (or if the lookup function getsserialized via state spinlock again).Fix this by prefetching state_hmask and the associated pointers.The xfrm_state_hash_generation seqlock retry will ensure that the pointerand the hmask will be consistent.The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,add lockdep assertions to document that they are only safe for insertside.xfrm_state_lookup_byaddr() uses the spinlock rather than RCU.AFAICS this is an oversight from back when state lookup was converted toRCU, this lock should be replaced with RCU in a future patch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57986 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: Fix assumption that Resolution Multipliers must be in Logical CollectionsA report in 2019 by the syzbot fuzzer was found to be connected to twoerrors in the HID core associated with Resolution Multipliers. One ofthe errors was fixed by commit ea427a222d8b ("HID: core: Fix deadloopin hid_apply_multiplier."), but the other has not been fixed.This error arises because hid_apply_multipler() assumes that everyResolution Multiplier control is contained in a Logical Collection,i.e., there's no way the routine can ever set multiplier_collection toNULL. This is in spite of the fact that the function starts with abig comment saying: * "The Resolution Multiplier control must be contained in the same * Logical Collection as the control(s) to which it is to be applied. ... * If no Logical Collection is * defined, the Resolution Multiplier is associated with all * controls in the report." * HID Usage Table, v1.12, Section 4.3.1, p30 * * Thus, search from the current collection upwards until we find a * logical collection...The comment and the code overlook the possibility that none of thecollections found may be a Logical Collection.The fix is to set the multiplier_collection pointer to NULL if thecollection found isn't a Logical Collection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-57993 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint checksyzbot has found a type mismatch between a USB pipe and the transferendpoint, which is triggered by the hid-thrustmaster driver[1].There is a number of similar, already fixed issues [2].In this case as in others, implementing check for endpoint type fixes the issue.[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470[2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Remove dangling pointersWhen an async control is written, we copy a pointer to the file handlethat started the operation. That pointer will be used when the device isdone. Which could be anytime in the future.If the user closes that file descriptor, its structure will be freed,and there will be one dangling pointer per pending async control, thatthe driver will try to use.Clean all the dangling pointers during release().To avoid adding a performance penalty in the most common case (no asyncoperation), a counter has been introduced with some logic to make surethat it is properly handled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58005 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Change to kvalloc() in eventlog/acpi.cThe following failure was reported on HPE ProLiant D320:[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)[ 10.848132][ T1] ------------[ cut here ]------------[ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330[ 10.862827][ T1] Modules linked in:[ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375[ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024[ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330[ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1[ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246[ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000[ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0The above transcript shows that ACPI pointed a 16 MiB buffer for the logevents because RSI maps to the 'order' parameter of __alloc_pages_noprof().Address the bug by moving from devm_kmalloc() to devm_add_action() andkvmalloc() and devm_add_action().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58007 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: socinfo: Avoid out of bounds read of serial numberOn MSM8916 devices, the serial number exposed in sysfs is constant and doesnot change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does nothave support for the serial_num field in the socinfo struct. There is anexisting check to avoid exposing the serial number in that case, but it'snot correct: When checking the item_size returned by SMEM, we need to makesure the *end* of the serial_num is within bounds, instead of comparingwith the *start* offset. The serial_number currently exposed on MSM8916devices is just an out of bounds read of whatever comes after the socinfostruct in SMEM.Fix this by changing offsetof() to offsetofend(), so that the size of thefield is also taken into account.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58009 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_allocA NULL sock pointer is passed into l2cap_sock_alloc() when it is calledfrom l2cap_sock_new_connection_cb() and the error handling paths shouldalso be aware of it.Seemingly a more elegant solution would be to swap bt_sock_alloc() andl2cap_chan_create() calls since they are not interdependent to that momentbut then l2cap_chan_create() adds the soon to be deallocated and stilldummy-initialized channel to the global list accessible by many L2CAPpaths. The channel would be removed from the list in short period of timebut be a bit more straight-forward here and just check for NULL instead ofchanging the order of function calls.Found by Linux Verification Center (linuxtesting.org) with SVACE staticanalysis tool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58011 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: int3472: Check for adev == NULLNot all devices have an ACPI companion fwnode, so adev might be NULL. Thiscan e.g. (theoretically) happen when a user manually binds one ofthe int3472 drivers to another i2c/platform device through sysfs.Add a check for adev not being set and return -ENODEV in that case toavoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58034 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()As of_find_node_by_name() release the reference of the argument devicenode, tegra_emc_find_node_by_ram_code() releases some device nodes whilestill in use, resulting in possible UAFs. According to the bindings andthe in-tree DTS files, the "emc-tables" node is always device's childnode with the property "nvidia,use-ram-code", and the "lpddr2" node is achild of the "emc-tables" node. Thus utilize thefor_each_child_of_node() macro and of_get_child_by_name() instead ofof_find_node_by_name() to simplify the code.This bug was found by an experimental verification tool that I amdeveloping.[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58051 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipmi: ipmb: Add check devm_kasprintf() returned valuedevm_kasprintf() can return a NULL pointer on failure but thisreturned value is not checked.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58052 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58053 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix handling of received connection abortFix the handling of a connection abort that we've received. Though theabort is at the connection level, it needs propagating to the calls on thatconnection. Whilst the propagation bit is performed, the calls aren't thenwoken up to go and process their termination, and as no further input isforthcoming, they just hang.Also add some tracing for the logging of connection aborts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58055 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_tcm: Don't free command immediatelyDon't prematurely free the command. Wait for the status completion ofthe sense status. It can be freed then. Otherwise we will double-freethe command.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58057 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: convert workqueues to unboundWhen a workqueue is created with `WQ_UNBOUND`, its work items areserved by special worker-pools, whose host workers are not bound toany specific CPU. In the default configuration (i.e. when`queue_delayed_work` and friends do not specify which CPU to run thework item on), `WQ_UNBOUND` allows the work item to be executed on anyCPU in the same node of the CPU it was enqueued on. While thissolution potentially sacrifices locality, it avoids contention withother processes that might dominate the CPU time of the processor thework item was scheduled on.This is not just a theoretical problem: in a particular scenariomisconfigured process was hogging most of the time from CPU0, leavingless than 0.5% of its CPU time to the kworker. The IDPF workqueuesthat were using the kworker on CPU0 suffered large completion delaysas a result, causing performance degradation, timeouts and eventualsystem crash.* I have also run a manual test to gauge the performance improvement. The test consists of an antagonist process (`./stress --cpu 2`) consuming as much of CPU 0 as possible. This process is run under `taskset 01` to bind it to CPU0, and its priority is changed with `chrt -pQ 9900 10000 ${pid}` and `renice -n -20 ${pid}` after start. Then, the IDPF driver is forced to prefer CPU0 by editing all calls to `queue_delayed_work`, `mod_delayed_work`, etc... to use CPU 0. Finally, `ktraces` for the workqueue events are collected. Without the current patch, the antagonist process can force arbitrary delays between `workqueue_queue_work` and `workqueue_execute_start`, that in my tests were as high as `30ms`. With the current patch applied, the workqueue can be migrated to another unloaded CPU in the same node, and, keeping everything else equal, the maximum delay I could see was `6us`.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58058 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ubifs: skip dumping tnc tree when zroot is nullClearing slab cache will free all znode in memory and makec->zroot.znode = NULL, then dumping tnc tree will accessc->zroot.znode which cause null pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58063 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtlwifi: fix memory leaks and invalid access at probe error pathDeinitialize at reverse order when probe fails.When init_sw_vars fails, rtl_deinit_core should not be called, speciallynow that it destroys the rtl_wq workqueue.And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will beleaked.Remove pci_set_drvdata call as it will already be cleaned up by the coredriver code and could lead to memory leaks too. cf. commit 8d450935ae7f("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") andcommit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM readThe nvmem interface supports variable buffer sizes, while the regmapinterface operates with fixed-size storage. If an nvmem client uses abuffer size less than 4 bytes, regmap_read will write out of boundsas it expects the buffer to point at an unsigned int.Fix this by using an intermediary unsigned int to hold the value.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58071 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:team: prevent adding a device which is already a team device lowerPrevent adding a device which is already a team device lower,e.g. adding veth0 if vlan1 was already added and veth0 is a lower ofvlan1.This is not useful in practice and can lead to recursive locking:$ ip link add veth0 type veth peer name veth1$ ip link set veth0 up$ ip link set veth1 up$ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1$ ip link add team0 type team$ ip link set veth0.1 down$ ip link set veth0.1 master team0team0: Port device veth0.1 added$ ip link set veth0 down$ ip link set veth0 master team0============================================WARNING: possible recursive locking detected6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted--------------------------------------------ip/7684 is trying to acquire lock:ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)but task is already holding lock:ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)other info that might help us debug this:Possible unsafe locking scenario:CPU0----lock(team->team_lock_key);lock(team->team_lock_key);*** DEADLOCK ***May be due to missing lock nesting notation2 locks held by ip/7684:stack backtrace:CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46Hardware 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_deadlock_bug.cold (kernel/locking/lockdep.c:3040)__lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? lock_acquire (kernel/locking/lockdep.c:5822)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)__mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? fib_sync_up (net/ipv4/fib_semantics.c:2167)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)notifier_call_chain (kernel/notifier.c:85)call_netdevice_notifiers_info (net/core/dev.c:1996)__dev_notify_flags (net/core/dev.c:8993)? __dev_change_flags (net/core/dev.c:8975)dev_change_flags (net/core/dev.c:9027)vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)? br_device_event (net/bridge/br.c:143)notifier_call_chain (kernel/notifier.c:85)call_netdevice_notifiers_info (net/core/dev.c:1996)dev_open (net/core/dev.c:1519 net/core/dev.c:1505)team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)do_set_master (net/core/rtnetlink.c:2917)do_setlink.isra.0 (net/core/rtnetlink.c:3117)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58072 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtlwifi: remove unused check_buddy_privCommit 2461c7d60f9f ("rtlwifi: Update header file") introduced a globallist of private data structures.Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to matchvendor version 2013.02.07") started adding the private data to that list atprobe time and added a hook, check_buddy_priv to find the private data froma similar device.However, that function was never used.Besides, though there is a lock for that list, it is never used. And whenthe probe fails, the private data is never removed from the list. Thiswould cause a second probe to access freed memory.Remove the unused hook, structures and members, which will prevent thepotential race condition on the list and its corruption during a secondprobe when probe fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58079 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix crash during unbind if gpio unit is in useWe used the wrong device for the device managed functions. We used theusb device, when we should be using the interface device.If we unbind the driver from the usb interface, the cleanup functionsare never called. In our case, the IRQ is never disabled.If an IRQ is triggered, it will try to access memory sections that arealready free, causing an OOPS.We cannot use the function devm_request_threaded_irq here. The devm_*clean functions may be called after the main structure is released byuvc_delete.Luckily this bug has small impact, as it is only affected by deviceswith gpio units and the user has to unbind the device, a disconnect willnot trigger this error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58089 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix double accounting race when btrfs_run_delalloc_range() failed[BUG]When running btrfs with block size (4K) smaller than page size (64K,aarch64), there is a very high chance to crash the kernel atgeneric/750, with the following messages:(before the call traces, there are 3 extra debug messages added) BTRFS warning (device dm-3): read-write for sector size 4096 with page size 65536 is experimental BTRFS info (device dm-3): checking UUID tree hrtimer: interrupt took 5451385 ns BTRFS error (device dm-3): cow_file_range failed, root=4957 inode=257 start=1605632 len=69632: -28 BTRFS error (device dm-3): run_delalloc_nocow failed, root=4957 inode=257 start=1605632 len=69632: -28 BTRFS error (device dm-3): failed to run delalloc range, root=4957 ino=257 folio=1572864 submit_bitmap=8-15 start=1605632 len=69632: -28 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3020984 at ordered-data.c:360 can_finish_ordered_extent+0x370/0x3b8 [btrfs] CPU: 2 UID: 0 PID: 3020984 Comm: kworker/u24:1 Tainted: G OE 6.13.0-rc1-custom+ #89 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : can_finish_ordered_extent+0x370/0x3b8 [btrfs] lr : can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] Call trace: can_finish_ordered_extent+0x370/0x3b8 [btrfs] (P) can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] (L) btrfs_mark_ordered_io_finished+0x130/0x2b8 [btrfs] extent_writepage+0x10c/0x3b8 [btrfs] extent_write_cache_pages+0x21c/0x4e8 [btrfs] btrfs_writepages+0x94/0x160 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x74/0xa0 start_delalloc_inodes+0x17c/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x17c/0x288 [btrfs] shrink_delalloc+0x11c/0x280 [btrfs] flush_space+0x288/0x328 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x228/0x680 worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1605632 OE len=16384 to_dec=16384 left=0 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1622016 OE len=12288 to_dec=12288 left=0 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1634304 OE len=8192 to_dec=4096 left=0 CPU: 1 UID: 0 PID: 3286940 Comm: kworker/u24:3 Tainted: G W OE 6.13.0-rc1-custom+ #89 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: btrfs_work_helper [btrfs] (btrfs-endio-write) pstate: 404000c5 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : process_one_work+0x110/0x680 lr : worker_thread+0x1bc/0x360 Call trace: process_one_work+0x110/0x680 (P) worker_thread+0x1bc/0x360 (L) worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: f84086a1 f9000fe1 53041c21 b9003361 (f9400661) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 2-3 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: 0x275bb9540000 from 0xffff800080000000 PHYS_OFFSET: 0xffff8fbba0000000 CPU features: 0x100,00000070,00801250,8201720b[CAUSE]The above warning is triggered immediately after the delalloc rangefailure, this happens in the following sequence:- Range [1568K, 1636K) is dirty 1536K 1568K 1600K 1636K 1664K | |/////////|////////| | Where 1536K, 1600K and 1664K are page boundaries (64K page size)- Enter extent_writepage() for page 1536K- Enter run_delalloc_nocow() with locke---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58093 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free"), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link->downstream would point to free'd memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.[kwilczynski: commit log]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58097 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix RCU stall while reaping monitor destination ringWhile processing the monitor destination ring, MSDUs are reaped from thelink descriptor based on the corresponding buf_id.However, sometimes the driver cannot obtain a valid buffer correspondingto the buf_id received from the hardware. This causes an infinite loopin the destination processing, resulting in a kernel crash.kernel log:ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failedath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failedFix this by skipping the problematic buf_id and reaping the next entry,replacing the break with the next MSDU processing.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58098 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: track changes_pkt_data property for global functionsWhen processing calls to certain helpers, verifier invalidates allpacket pointers in a current state. For example, consider thefollowing program: __attribute__((__noinline__)) long skb_pull_data(struct __sk_buff *sk, __u32 len) { return bpf_skb_pull_data(sk, len); } SEC("tc") int test_invalidate_checks(struct __sk_buff *sk) { int *p = (void *)(long)sk->data; if ((void *)(p + 1) > (void *)(long)sk->data_end) return TCX_DROP; skb_pull_data(sk, 0); *p = 42; return TCX_PASS; }After a call to bpf_skb_pull_data() the pointer 'p' can't be usedsafely. See function filter.c:bpf_helper_changes_pkt_data() for a listof such helpers.At the moment verifier invalidates packet pointers when processinghelper function calls, and does not traverse global sub-programs whenprocessing calls to global sub-programs. This means that calls tohelpers done from global sub-programs do not invalidate pointers inthe caller state. E.g. the program above is unsafe, but is notrejected by verifier.This commit fixes the omission by computing fieldbpf_subprog_info->changes_pkt_data for each sub-program before mainverification pass.changes_pkt_data should be set if:- subprogram calls helper for which bpf_helper_changes_pkt_data returns true;- subprogram calls a global function, for which bpf_subprog_info->changes_pkt_data should be set.The verifier.c:check_cfg() pass is modified to compute thisinformation. The commit relies on depth first instruction traversaldone by check_cfg() and absence of recursive function calls:- check_cfg() would eventually visit every call to subprogram S in a state when S is fully explored;- when S is fully explored: - every direct helper call within S is explored (and thus changes_pkt_data is set if needed); - every call to subprogram S1 called by S was visited with S1 fully explored (and thus S inherits changes_pkt_data from S1).The downside of such approach is that dead code elimination is nottaken into account: if a helper call inside global function is deadbecause of current configuration, verifier would conservatively assumethat the call occurs for the purpose of the changes_pkt_datacomputation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58100 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: check changes_pkt_data property for extension programsWhen processing calls to global sub-programs, verifier decides whetherto invalidate all packet pointers in current state depending on thechanges_pkt_data property of the global sub-program.Because of this, an extension program replacing a global sub-programmust be compatible with changes_pkt_data property of the sub-programbeing replaced.This commit:- adds changes_pkt_data flag to struct bpf_prog_aux: - this flag is set in check_cfg() for main sub-program; - in jit_subprogs() for other sub-programs;- modifies bpf_check_attach_btf_id() to check changes_pkt_data flag;- moves call to check_attach_btf_id() after the call to check_cfg(), because it needs changes_pkt_data flag to be set: bpf_check: ... ... - check_attach_btf_id resolve_pseudo_ldimm64 resolve_pseudo_ldimm64 --> bpf_prog_is_offloaded bpf_prog_is_offloaded check_cfg check_cfg + check_attach_btf_id ... ...The following fields are set by check_attach_btf_id():- env->ops- prog->aux->attach_btf_trace- prog->aux->attach_func_name- prog->aux->attach_func_proto- prog->aux->dst_trampoline- prog->aux->mod- prog->aux->saved_dst_attach_type- prog->aux->saved_dst_prog_type- prog->expected_attach_typeNeither of these fields are used by resolve_pseudo_ldimm64() orbpf_prog_offload_verifier_prep() (for netronome and netdevsimdrivers), so the reordering is safe.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2024-58237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: consider that tail calls invalidate packet pointersTail-called programs could execute any of the helpers that invalidatepacket pointers. Hence, conservatively assume that each tail callinvalidates packet pointers.Making the change in bpf_helper_changes_pkt_data() automatically makesuse of check_cfg() logic that computes 'changes_pkt_data' effect forglobal sub-programs, such that the following program could berejected: int tail_call(struct __sk_buff *sk) { bpf_tail_call_static(sk, &jmp_table, 0); return 0; } SEC("tc") int not_safe(struct __sk_buff *sk) { int *p = (void *)(long)sk->data; ... make p valid ... tail_call(sk); *p = 42; /* this is unsafe */ ... }The tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function thatcan invalidate packet pointers. Otherwise, it can't be freplaced withtailcall_freplace.c:entry_freplace() that does a tail call.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-15649 Severity: Moderate CVSS3 score: 5.5

Description: IO::Uncompress::Unzip versions before 2.215 for Perl propagate uncaught exception when parsing zip header with malformed DOS date._dosToUnixTime() decodes the local-file-header last-modification date field and calls Time::Local::timelocal() without an eval guard. A header whose date field decodes to an out-of-range month, day, or hour causes timelocal() to die.The exception propagates out of IO::Uncompress::Unzip->new($file) where callers expect undef plus $UnzipError.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
perl > 0-0 (version in image is 5.26.1-150300.17.20.1).

CVE-2025-21635 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The per-netns structure can be obtained from the table->data usingcontainer_of(), then the 'net' one can be retrieved from the listensocket (if available).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21636 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: plpmtud_probe_interval: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.probe_interval' isused.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21637 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: udp_port: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, but that wouldincrease the size of this fix, while 'sctp.ctl_sock' still needs to beretrieved from 'net' structure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21638 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: auth_enable: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, but that wouldincrease the size of this fix, while 'sctp.ctl_sock' still needs to beretrieved from 'net' structure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21639 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: rto_min/max: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.rto_min/max' is used.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21640 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.sctp_hmac_alg' isused.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21646 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix the maximum cell name lengthThe kafs filesystem limits the maximum length of a cell to 256 bytes, but aproblem occurs if someone actually does that: kafs tries to create adirectory under /proc/net/afs/ with the name of the cell, but that failswith a warning: WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405because procfs limits the maximum filename length to 255.However, the DNS limits the maximum lookup length and, by extension, themaximum cell name, to 255 less two (length count and trailing NUL).Fix this by limiting the maximum acceptable cellname length to 253. Thisalso allows us to be sure we can create the "/afs/./" mountpoint too.Further, split the YFS VL record cell name maximum to be the 256 allowed bythe protocol and ignore the record retrieved by YFSVL.GetCellName if itexceeds 253.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21649 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when 1588 is sent on HIP08 devicesCurrently, HIP08 devices does not register the ptp devices, so thehdev->ptp is NULL. But the tx process would still try to set hardware timestamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash.[ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018...[ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge][ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge][ 128.292938] sp : ffff800059b93140[ 128.297200] x29: ffff800059b93140 x28: 0000000000003280[ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080[ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001[ 128.315969] x23: 0000000000000000 x22: 0000000000000194[ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000[ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000[ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24[ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000[ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368[ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02[ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0[ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000[ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff[ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294[ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080[ 128.390626] Call trace:[ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge][ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3][ 128.405468] xmit_one.constprop.0+0xc4/0x200[ 128.410600] dev_hard_start_xmit+0x54/0xf0[ 128.415556] sch_direct_xmit+0xe8/0x634[ 128.420246] __dev_queue_xmit+0x224/0xc70[ 128.425101] dev_queue_xmit+0x1c/0x40[ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch][ 128.435409] do_output+0x60/0x17c [openvswitch][ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch][ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch][ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch][ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch][ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch][ 128.471460] xmit_one.constprop.0+0xc4/0x200[ 128.476561] dev_hard_start_xmit+0x54/0xf0[ 128.481489] __dev_queue_xmit+0x968/0xc70[ 128.486330] dev_queue_xmit+0x1c/0x40[ 128.490856] ip_finish_output2+0x250/0x570[ 128.495810] __ip_finish_output+0x170/0x1e0[ 128.500832] ip_finish_output+0x3c/0xf0[ 128.505504] ip_output+0xbc/0x160[ 128.509654] ip_send_skb+0x58/0xd4[ 128.513892] udp_send_skb+0x12c/0x354[ 128.518387] udp_sendmsg+0x7a8/0x9c0[ 128.522793] inet_sendmsg+0x4c/0x8c[ 128.527116] __sock_sendmsg+0x48/0x80[ 128.531609] __sys_sendto+0x124/0x164[ 128.536099] __arm64_sys_sendto+0x30/0x5c[ 128.540935] invoke_syscall+0x50/0x130[ 128.545508] el0_svc_common.constprop.0+0x10c/0x124[ 128.551205] do_el0_svc+0x34/0xdc[ 128.555347] el0_svc+0x20/0x30[ 128.559227] el0_sync_handler+0xb8/0xc0[ 128.563883] el0_sync+0x160/0x180

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21665 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21666 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: prevent null-ptr-deref in vsock_*[has_data|has_space]Recent reports have shown how we sometimes call vsock_*_has_data()when a vsock socket has been de-assigned from a transport (see attachedlinks), but we shouldn't.Previous commits should have solved the real problems, but we may havemore in the future, so to avoid null-ptr-deref, we can return 0(no space, no data available) but with a warning.This way the code should continue to run in a nearly consistent stateand have a warning that allows us to debug future problems.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21675 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Clear port select structure when fail to createClear the port select structure on error so no stale values left afterdefiners are destroyed. That's because the mlx5_lag_destroy_definers()always try to destroy all lag definers in the tt_map, so in the flowbelow lag definers get double-destroyed and cause kernel crash: mlx5_lag_port_sel_create() mlx5_lag_create_definers() mlx5_lag_create_definer() <- Failed on tt 1 mlx5_lag_destroy_definers() <- definers[tt=0] gets destroyed mlx5_lag_port_sel_create() mlx5_lag_create_definers() mlx5_lag_create_definer() <- Failed on tt 0 mlx5_lag_destroy_definers() <- definers[tt=0] gets double-destroyed Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 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 fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 64k pages, 48-bit VAs, pgdp=0000000112ce2e00 [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Modules linked in: iptable_raw bonding ip_gre ip6_gre gre ip6_tunnel tunnel6 geneve ip6_udp_tunnel udp_tunnel ipip tunnel4 ip_tunnel rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) mlx5_fwctl(OE) fwctl(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlxfw(OE) memtrack(OE) mlx_compat(OE) openvswitch nsh nf_conncount psample xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc netconsole overlay efi_pstore sch_fq_codel zram ip_tables crct10dif_ce qemu_fw_cfg fuse ipv6 crc_ccitt [last unloaded: mlx_compat(OE)] CPU: 3 UID: 0 PID: 217 Comm: kworker/u53:2 Tainted: G OE 6.11.0+ #2 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Workqueue: mlx5_lag mlx5_do_bond_work [mlx5_core] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mlx5_del_flow_rules+0x24/0x2c0 [mlx5_core] lr : mlx5_lag_destroy_definer+0x54/0x100 [mlx5_core] sp : ffff800085fafb00 x29: ffff800085fafb00 x28: ffff0000da0c8000 x27: 0000000000000000 x26: ffff0000da0c8000 x25: ffff0000da0c8000 x24: ffff0000da0c8000 x23: ffff0000c31f81a0 x22: 0400000000000000 x21: ffff0000da0c8000 x20: 0000000000000000 x19: 0000000000000001 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff8b0c9350 x14: 0000000000000000 x13: ffff800081390d18 x12: ffff800081dc3cc0 x11: 0000000000000001 x10: 0000000000000b10 x9 : ffff80007ab7304c x8 : ffff0000d00711f0 x7 : 0000000000000004 x6 : 0000000000000190 x5 : ffff00027edb3010 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff0000d39b8000 x1 : ffff0000d39b8000 x0 : 0400000000000000 Call trace: mlx5_del_flow_rules+0x24/0x2c0 [mlx5_core] mlx5_lag_destroy_definer+0x54/0x100 [mlx5_core] mlx5_lag_destroy_definers+0xa0/0x108 [mlx5_core] mlx5_lag_port_sel_create+0x2d4/0x6f8 [mlx5_core] mlx5_activate_lag+0x60c/0x6f8 [mlx5_core] mlx5_do_bond_work+0x284/0x5c8 [mlx5_core] process_one_work+0x170/0x3e0 worker_thread+0x2d8/0x3e0 kthread+0x11c/0x128 ret_from_fork+0x10/0x20 Code: a9025bf5 aa0003f6 a90363f7 f90023f9 (f9400400) ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21678 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: Destroy device along with udp socket's netns dismantle.gtp_newlink() links the device to a list in dev_net(dev) instead ofsrc_net, where a udp tunnel socket is created.Even when src_net is removed, the device stays alive on dev_net(dev).Then, removing src_net triggers the splat below. [0]In this example, gtp0 is created in ns2, and the udp socket is createdin ns1. ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1Let's link the device to the socket's netns instead.Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to removeall gtp devices in the netns.[0]:ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347) netlink_sendmsg (net/netlink/af_netlink.c:1891) ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) ___sys_sendmsg (net/socket.c:2639) __sys_sendmsg (net/socket.c:2669) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)Modules linked in:CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Workqueue: netns cleanup_netRIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89RSP: 0018:ff11000009a07b60 EFLAGS: 00010286RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3cRBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395aeR10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? __warn (kernel/panic.c:748) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:285) ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467) cleanup_net (net/core/net_namespace.c:664 (discriminator 3)) process_one_work (kernel/workqueue.c:3229) worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21689 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()This patch addresses a null-ptr-deref in qt2_process_read_urb() due toan incorrect bounds check in the following: if (newport > serial->num_ports) { dev_err(&port->dev, "%s - port change to invalid port: %i\n", __func__, newport); break; }The condition doesn't account for the valid range of the serial->portbuffer, which is from 0 to serial->num_ports - 1. When newport is equalto serial->num_ports, the assignment of "port" in thefollowing code is out-of-bounds and NULL: serial_priv->current_port = newport; port = serial->port[serial_priv->current_port];The fix checks if newport is greater than or equal to serial->num_portsindicating it is out-of-bounds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21696 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: clear uffd-wp PTE/PMD state on mremap()When mremap()ing a memory region previously registered with userfaultfd aswrite-protected but without UFFD_FEATURE_EVENT_REMAP, an inconsistency inflag clearing leads to a mismatch between the vma flags (which haveuffd-wp cleared) and the pte/pmd flags (which do not have uffd-wpcleared). This mismatch causes a subsequent mprotect(PROT_WRITE) totrigger a warning in page_table_check_pte_flags() due to setting the pteto writable while uffd-wp is still set.Fix this by always explicitly clearing the uffd-wp pte/pmd flags on anysuch mremap() so that the values are consistent with the existing clearingof VM_UFFD_WP. Be careful to clear the logical flag regardless of itsphysical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE,huge PMD and hugetlb paths.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21707 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: consolidate suboption statusMPTCP maintains the received sub-options status is the bitmask carryingthe received suboptions and in several bitfields carrying per suboptionadditional info.Zeroing the bitmask before parsing is not enough to ensure a consistentstatus, and the MPTCP code has to additionally clear some bitfileddepending on the actually parsed suboption.The above schema is fragile, and syzbot managed to trigger a path wherea relevant bitfield is not cleared/initialized: BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21708 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: rtl8150: enable basic endpoint checkingSyzkaller reports [1] encountering a common issue of utilizing a wrongusb endpoint type during URB submitting stage. This, in turn, triggersa warning shown below.For now, enable simple endpoint checking (specifically, bulk andinterrupt eps, testing control one is not essential) to mitigatethe issue with a view to do other related cosmetic changes later,if they are necessary.[1] Syzkaller report:usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv>Modules linked in:CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617>Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8>RSP: 0018:ffffc9000441f740 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7cFS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 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+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fc04ef73d49...This change has not been tested on real hardware.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21712 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetimeAfter commit ec6bb299c7c3 ("md/md-bitmap: add 'sync_size' into structmd_bitmap_stats"), following panic is reported:Oops: general protection fault, probably for non-canonical addressRIP: 0010:bitmap_get_stats+0x2b/0xa0Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7eRoot cause is that bitmap_get_stats() can be called at anytime if mddevis still there, even if bitmap is destroyed, or not fully initialized.Deferenceing bitmap in this case can crash the kernel. Meanwhile, theabove commit start to deferencing bitmap->storage, make the problemeasier to trigger.Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21715 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: davicom: fix UAF in dm9000_drv_removedm is netdev private data and it cannot beused after free_netdev() call. Using dm after free_netdev()can cause UAF bug. Fix it by moving free_netdev() at the end of thefunction.This is similar to the issue fixed in commitad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").This bug is detected by our static analysis tool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21719 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipmr: do not call mr_mfc_uses_dev() for unres entriessyzbot found that calling mr_mfc_uses_dev() for unres entrieswould crash [1], because c->mfc_un.res.minvif / c->mfc_un.res.maxvifalias to "struct sk_buff_head unresolved", which contain two pointers.This code never worked, lets remove it.[1]Unable to handle kernel paging request at virtual address ffff5fff2d536613KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f]Modules linked in:CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334Call trace: mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P) mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P) mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317 netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg net/socket.c:1055 [inline] sock_read_iter+0x2d8/0x40c net/socket.c:1125 new_sync_read fs/read_write.c:484 [inline] vfs_read+0x740/0x970 fs/read_write.c:565 ksys_read+0x15c/0x26c fs/read_write.c:708

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21727 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:padata: fix UAF in padata_reorderA bug was found when run ltp test:BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+Workqueue: pdecrypt_parallel padata_parallel_workerCall Trace:dump_stack_lvl+0x32/0x50print_address_description.constprop.0+0x6b/0x3d0print_report+0xdd/0x2c0kasan_report+0xa5/0xd0padata_find_next+0x29/0x1a0padata_reorder+0x131/0x220padata_parallel_worker+0x3d/0xc0process_one_work+0x2ec/0x5a0If 'mdelay(10)' is added before calling 'padata_find_next' in the'padata_reorder' function, this issue could be reproduced easily withltp test (pcrypt_aead01).This can be explained as bellow:pcrypt_aead_encrypt...padata_do_parallelrefcount_inc(&pd->refcnt); // add refcnt...padata_do_serialpadata_reorder // pdwhile (1) {padata_find_next(pd, true); // using pdqueue_work_on...padata_serial_worker crypto_del_algpadata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed// loop again, but pd is freed// call padata_find_next, UAF}In the padata_reorder function, when it loops in 'while', if the alg isdeleted, the refcnt may be decreased to 0 before entering'padata_find_next', which leads to UAF.As mentioned in [1], do_serial is supposed to be called with BHs disabledand always happen under RCU protection, to address this issue, addsynchronize_rcu() in 'padata_free_shell' wait for all _do_serial callsto finish.[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21728 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Send signals asynchronously if !preemptibleBPF programs can execute in all kinds of contexts and when a programrunning in a non-preemptible context uses the bpf_send_signal() kfunc,it will cause issues because this kfunc can sleep.Change `irqs_disabled()` to `!preemptible()`.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21731 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nbd: don't allow reconnect after disconnectFollowing process can cause nbd_config UAF:1) grab nbd_config temporarily;2) nbd_genl_disconnect() flush all recv_work() and release theinitial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work)4) step 1) release the reference;5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAFFix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), sothat nbd_genl_reconfigure() will fail.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21734 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:misc: fastrpc: Fix copy buffer page sizeFor non-registered buffer, fastrpc driver copies the buffer andpass it to the remote subsystem. There is a problem with currentimplementation of page size calculation which is not consideringthe offset in the calculation. This might lead to passing ofimproper and out-of-bounds page size which could result inmemory issue. Calculate page start and page end using the offsetadjusted address instead of absolute address.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21735 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: Add bounds checking in nci_hci_create_pipe()The "pipe" variable is a u8 which comes from the network. If it's morethan 127, then it results in memory corruption in the caller,nci_hci_connect_gate().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21744 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if()Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21745 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: Fix class @block_class's subsystem refcount leakageblkcg_fill_root_iostats() iterates over @block_class's devices byclass_dev_iter_(init|next)(), but does not end iterating withclass_dev_iter_exit(), so causes the class's subsystem refcount leakage.Fix by ending the iterating with class_dev_iter_exit().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21750 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Check the return value of of_property_read_string_index()Somewhen between 6.10 and 6.11 the driver started to crash on myMacBookPro14,3. The property doesn't exist and 'tmp' remainsuninitialized, so we pass a random pointer to devm_kstrdup().The crash I am getting looks like this:BUG: unable to handle page fault for address: 00007f033c669379PF: supervisor read access in kernel modePF: error_code(0x0001) - permissions violationPGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025Oops: Oops: 0001 [#1] SMP PTICPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024RIP: 0010:strlen+0x4/0x30Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 ccRSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916aR10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x149/0x4c0 ? raw_spin_rq_lock_nested+0xe/0x20 ? sched_balance_newidle+0x22b/0x3c0 ? update_load_avg+0x78/0x770 ? exc_page_fault+0x6f/0x150 ? asm_exc_page_fault+0x26/0x30 ? __pfx_pci_conf1_write+0x10/0x10 ? strlen+0x4/0x30 devm_kstrdup+0x25/0x70 brcmf_of_probe+0x273/0x350 [brcmfmac]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21758 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: add RCU protection to mld_newpack()mld_newpack() can be called without RTNL or RCU being held.Note that we no longer can use sock_alloc_send_skb() becauseipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.Instead use alloc_skb() and charge the net->ipv6.igmp_sksocket under RCU protection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21759 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: extend RCU protection in igmp6_send()igmp6_send() can be called without RTNL or RCU being held.Extend RCU protection so that we can safely fetch the net pointerand avoid a potential UAF.Note that we no longer can use sock_alloc_send_skb() becauseipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.Instead use alloc_skb() and charge the net->ipv6.igmp_sksocket under RCU protection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21761 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: use RCU protection in ovs_vport_cmd_fill_info()ovs_vport_cmd_fill_info() can be called without RTNL or RCU.Use RCU protection and dev_net_rcu() to avoid potential UAF.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21762 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arp: use RCU protection in arp_xmit()arp_xmit() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21763 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:neighbour: use RCU protection in __neigh_notify()__neigh_notify() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21767 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic contextThe following bug report happened with a PREEMPT_RT kernel: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0It is due to the fact that clocksource_verify_choose_cpus() is invoked withpreemption disabled. This function invokes get_random_u32() to obtainrandom numbers for choosing CPUs. The batched_entropy_32 local lock and/orthe base_crng.lock spinlock in driver/char/random.c will be acquired duringthe call. In PREEMPT_RT kernel, they are both sleeping locks and so cannotbe acquired in atomic context.Fix this problem by using migrate_disable() to allow smp_processor_id() tobe reliably used without introducing atomic context. preempt_disable() isthen called after clocksource_verify_choose_cpus() but before theclocksource measurement is being run to avoid introducing unexpectedlatency.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21768 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnelsSome lwtunnels have a dst cache for post-transformation dst.If the packet destination did not change we may end up recordinga reference to the lwtunnel in its own cache, and the lwtunnelstate will never be freed.Discovered by the ioam6.sh test, kmemleak was recently fixedto catch per-cpu memory leaks. I'm not sure if rpl and seg6can actually hit this, but in principle I don't see why not.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21776 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: hub: Ignore non-compliant devices with too many configs or interfacesRobert Morris created a test program which can causeusb_hub_to_struct_hub() to dereference a NULL or inappropriatepointer:Oops: general protection fault, probably for non-canonical address0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTICPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110...Call Trace: ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0The cause of this error is that the device has two interfaces, and thehub driver binds to interface 1 instead of interface 0, which is whereusb_hub_to_struct_hub() looks.We can prevent the problem from occurring by refusing to accept hubdevices that violate the USB spec by having more than oneconfiguration or interface.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21779 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernelAdvertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if andonly if the local API is emulated/virtualized by KVM, and explicitly rejectsaid hypercalls if the local APIC is emulated in userspace, i.e. don't relyon userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference ifHyper-V enlightenments are exposed to the guest without an in-kernel localAPIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1Note, checking the sending vCPU is sufficient, as the per-VM irqchip_modecan't be modified after vCPUs are created, i.e. if one vCPU has anin-kernel local APIC, then all vCPUs have an in-kernel local APIC.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21781 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: fix panic during interface removalReference counting is used to ensure thatbatadv_hardif_neigh_node and batadv_hard_ifaceare not freed before/duringbatadv_v_elp_throughput_metric_update work isfinished.But there isn't a guarantee that the hard if willremain associated with a soft interface up untilthe work is finished.This fixes a crash triggered by reboot that lookslike this:Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20(the batadv_v_mesh_free call is misleading,and does not actually happen)I was able to make the issue happen more reliablyby changing hardif_neigh->bat_v.metric_work workto be delayed work. This allowed me to track downand confirm the fix.[sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:team: better TEAM_OPTION_TYPE_STRING validationsyzbot reported following splat [1]Make sure user-provided data contains one nul byte.[1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21792 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: Fix refcount leak caused by setting SO_BINDTODEVICE sockoptIf an AX25 device is bound to a socket by setting the SO_BINDTODEVICEsocket option, a refcount leak will occur in ax25_release().Commit 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()")added decrement of device refcounts in ax25_release(). In order for thatto work correctly the refcounts must already be incremented when thedevice is bound to the socket. An AX25 device can be bound to a socketby either calling ax25_bind() or setting SO_BINDTODEVICE socket option.In both cases the refcounts should be incremented, but in fact it is doneonly in ax25_bind().This bug leads to the following issue reported by Syzkaller:================================================================refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 1 PID: 5932 at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31Modules linked in:CPU: 1 UID: 0 PID: 5932 Comm: syz-executor424 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31Call Trace: __refcount_dec include/linux/refcount.h:336 [inline] refcount_dec include/linux/refcount.h:351 [inline] ref_tracker_free+0x710/0x820 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4156 [inline] netdev_put include/linux/netdevice.h:4173 [inline] netdev_put include/linux/netdevice.h:4169 [inline] ax25_release+0x33f/0xa10 net/ax25/af_ax25.c:1069 __sock_release+0xb0/0x270 net/socket.c:640 sock_close+0x1c/0x30 net/socket.c:1408 ... do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... ================================================================Fix the implementation of ax25_setsockopt() by adding increment ofrefcounts for the new device bound, and decrement of refcounts forthe old unbound device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21796 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: clear acl_access/acl_default after releasing themIf getting acl_default fails, acl_access and acl_default will be releasedsimultaneously. However, acl_access will still retain a pointer pointingto the released posix_acl, which will trigger a WARNING innfs3svc_release_getacl like this:------------[ cut here ]------------refcount_t: underflow; use-after-free.WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28refcount_warn_saturate+0xb5/0x170Modules linked in:CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted6.12.0-rc6-00079-g04ae226af01f-dirty #8Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014RIP: 0010:refcount_warn_saturate+0xb5/0x170Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b ebcd 0f b6 1d 8a3RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fdeRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0FS: 0000000000000000(0000) GS:ffff88871ed00000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: kernel: panic_on_warn set ...Clear acl_access/acl_default after posix_acl_release is called to preventUAF from being triggered.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21799 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()When getting the IRQ we use k3_udma_glue_tx_get_irq() which returnsnegative error value on error. So not NULL check is not sufficientto deteremine if IRQ is valid. Check that IRQ is greater then zeroto ensure it is valid.There is no issue at probe time but at runtime user can invoke.set_channels which results in the following call chain.am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns()At this point if am65_cpsw_nuss_init_tx_chns() fails due tok3_udma_glue_tx_get_irq() then tx_chn->irq will be set to anegative value.Then, at subsequent .set_channels with higher channel count wewill attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns()leading to a kernel warning.The issue is present in the original commit that introduced this driver,although there, am65_cpsw_nuss_update_tx_rx_chns() existed asam65_cpsw_nuss_update_tx_chns().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21801 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ravb: Fix missing rtnl lock in suspend/resume pathFix the suspend/resume path by ensuring the rtnl lock is held whererequired. Calls to ravb_open, ravb_close and wol operations must beperformed under the rtnl lock to prevent conflicts with ongoing ndooperations.Without this fix, the following warning is triggered:[ 39.032969] =============================[ 39.032983] WARNING: suspicious RCU usage[ 39.033019] -----------------------------[ 39.033033] drivers/net/phy/phy_device.c:2004 suspiciousrcu_dereference_protected() usage!...[ 39.033597] stack backtrace:[ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7[ 39.033623] Hardware name: Renesas SMARC EVK version 2 based onr9a08g045s33 (DT)[ 39.033628] Call trace:[ 39.033633] show_stack+0x14/0x1c (C)[ 39.033652] dump_stack_lvl+0xb4/0xc4[ 39.033664] dump_stack+0x14/0x1c[ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c[ 39.033682] phy_detach+0x160/0x190[ 39.033694] phy_disconnect+0x40/0x54[ 39.033703] ravb_close+0x6c/0x1cc[ 39.033714] ravb_suspend+0x48/0x120[ 39.033721] dpm_run_callback+0x4c/0x14c[ 39.033731] device_suspend+0x11c/0x4dc[ 39.033740] dpm_suspend+0xdc/0x214[ 39.033748] dpm_suspend_start+0x48/0x60[ 39.033758] suspend_devices_and_enter+0x124/0x574[ 39.033769] pm_suspend+0x1ac/0x274[ 39.033778] state_store+0x88/0x124[ 39.033788] kobj_attr_store+0x14/0x24[ 39.033798] sysfs_kf_write+0x48/0x6c[ 39.033808] kernfs_fop_write_iter+0x118/0x1a8[ 39.033817] vfs_write+0x27c/0x378[ 39.033825] ksys_write+0x64/0xf4[ 39.033833] __arm64_sys_write+0x18/0x20[ 39.033841] invoke_syscall+0x44/0x104[ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4[ 39.033862] do_el0_svc+0x18/0x20[ 39.033870] el0_svc+0x3c/0xf0[ 39.033880] el0t_64_sync_handler+0xc0/0xc4[ 39.033888] el0t_64_sync+0x154/0x158[ 39.041274] ravb 11c30000.ethernet eth0: Link is Down

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21802 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix oops when unload drivers parallelingWhen unload hclge driver, it tries to disable sriov first for eachae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver atthe time, because it removes all the ae_dev nodes, and it may causeoops.But we can't simply use hnae3_common_lock for this. Because in theprocess flow of pci_disable_sriov(), it will trigger the remove flowof VF, which will also take hnae3_common_lock.To fixes it, introduce a new mutex to protect the unload process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21804 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()macro to request a needed resource. A string variable that lives on thestack is then used to store a dynamically computed resource name, whichis then passed on as one of the macro arguments. This can lead toundefined behavior.Depending on the current contents of the memory, the manifestations oferrors may vary. One possible output may be as follows: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff :Sometimes, garbage may appear after the colon.In very rare cases, if no NULL-terminator is found in memory, the systemmight crash because the string iterator will overrun which can lead toaccess of unmapped memory above the stack.Thus, fix this by replacing outbound_name with the name of the previouslyrequested resource. With the changes applied, the output will be asfollows: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3[kwilczynski: commit log]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21806 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: let net.core.dev_weight always be non-zeroThe following problem was encountered during stability test:(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \ returned 1, exceeding its budget of 0.------------[ cut here ]------------list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40.WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \ __list_add_valid_or_report+0xf3/0x130CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+RIP: 0010:__list_add_valid_or_report+0xf3/0x130Call Trace:? __warn+0xcd/0x250? __list_add_valid_or_report+0xf3/0x130enqueue_to_backlog+0x923/0x1070netif_rx_internal+0x92/0x2b0__netif_rx+0x15/0x170loopback_xmit+0x2ef/0x450dev_hard_start_xmit+0x103/0x490__dev_queue_xmit+0xeac/0x1950ip_finish_output2+0x6cc/0x1620ip_output+0x161/0x270ip_push_pending_frames+0x155/0x1a0raw_sendmsg+0xe13/0x1550__sys_sendto+0x3bf/0x4e0__x64_sys_sendto+0xdc/0x1b0do_syscall_64+0x5b/0x170entry_SYSCALL_64_after_hwframe+0x76/0x7eThe reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1This is because when the napi's weight is set to 0, process_backlog() mayreturn 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing thisnapi to be re-polled in net_rx_action() until __do_softirq() times out.Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() canbe retriggered in enqueue_to_backlog(), causing this issue.Making the napi's weight always non-zero solves this problem.Triggering this issue requires system-wide admin (setting isnot namespaced).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21814 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ptp: Ensure info->enable callback is always setThe ioctl and sysfs handlers unconditionally call the ->enable callback.Not all drivers implement that callback, leading to NULL dereferences.Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.Instead use a dummy callback if no better was specified by the driver.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21820 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tty: xilinx_uartps: split sysrq handlinglockdep detects the following circular locking dependency:CPU 0 CPU 1========================== ============================cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock()The fixed commit attempts to avoid this situation by only taking theport lock in cdns_uart_console_write if port->sysrq unset. However, if(as shown above) cdns_uart_console_write runs before port->sysrq is set,then it will try to take the port lock anyway. This may result in adeadlock.Fix this by splitting sysrq handling into two parts. We use the preparehelper under the port lock and defer handling until we release the lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21821 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: omap: use threaded IRQ for LCD DMAWhen using touchscreen and framebuffer, Nokia 770 crashes easily with: BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000 Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2 Hardware name: Nokia 770 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x54/0x5c dump_stack_lvl from __schedule_bug+0x50/0x70 __schedule_bug from __schedule+0x4d4/0x5bc __schedule from schedule+0x34/0xa0 schedule from schedule_preempt_disabled+0xc/0x10 schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4 __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4 clk_prepare_lock from clk_set_rate+0x18/0x154 clk_set_rate from sossi_read_data+0x4c/0x168 sossi_read_data from hwa742_read_reg+0x5c/0x8c hwa742_read_reg from send_frame_handler+0xfc/0x300 send_frame_handler from process_pending_requests+0x74/0xd0 process_pending_requests from lcd_dma_irq_handler+0x50/0x74 lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130 __handle_irq_event_percpu from handle_irq_event+0x28/0x68 handle_irq_event from handle_level_irq+0x9c/0x170 handle_level_irq from generic_handle_domain_irq+0x2c/0x3c generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c generic_handle_arch_irq from call_with_stack+0x1c/0x24 call_with_stack from __irq_svc+0x94/0xa8 Exception stack(0xc5255da0 to 0xc5255de8) 5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248 5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94 5de0: 60000013 ffffffff __irq_svc from clk_prepare_lock+0x4c/0xe4 clk_prepare_lock from clk_get_rate+0x10/0x74 clk_get_rate from uwire_setup_transfer+0x40/0x180 uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664 spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498 __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8 __spi_sync from spi_sync+0x24/0x40 spi_sync from ads7846_halfd_read_state+0x5c/0x1c0 ads7846_halfd_read_state from ads7846_irq+0x58/0x348 ads7846_irq from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x120/0x228 irq_thread from kthread+0xc8/0xe8 kthread from ret_from_fork+0x14/0x28As a quick fix, switch to a threaded IRQ which provides a stable system.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21823 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: Drop unmanaged ELP metric workerThe ELP worker needs to calculate new metric values for all neighbors"reachable" over an interface. Some of the used metric sources requirelocks which might need to sleep. This sleep is incompatible with the RCUlist iterator used for the recorded neighbors. The initial approach to workaround of this problem was to queue another work item per neighbor and thenrun this in a new context.Even when this solved the RCU vs might_sleep() conflict, it has a majorproblems: Nothing was stopping the work item in case it is not neededanymore - for example because one of the related interfaces was removed orthe batman-adv module was unloaded - resulting in potential invalid memoryaccesses.Directly canceling the metric worker also has various problems:* cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish.* iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must "stop" all still running workers)The better approch is to get rid of the per interface neighbor metricworker and handle everything in the interface worker. The original problemsare solved by:* creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context* only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21830 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:landlock: Handle weird filesA corrupted filesystem (e.g. bcachefs) might return weird files.Instead of throwing a warning and allowing access to such file, treatthem as regular files.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21831 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets thepolicy that all PCIe ports are allowed to use D3. When the system issuspended if the port is not power manageable by the platform and won't beused for wakeup via a PME this sets up the policy for these ports to gointo D3hot.This policy generally makes sense from an OSPM perspective but it leads toproblems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with aspecific old BIOS. This manifests as a system hang.On the affected Device + BIOS combination, add a quirk for the root port ofthe problematic controller to ensure that these root ports are not put intoD3hot at suspend.This patch is based on https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.combut with the added condition both in the documentation and in the code toapply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and onlythe affected root ports.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21835 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_midi: fix MIDI Streaming descriptor lengthsWhile the MIDI jacks are configured correctly, and the MIDIStreamingendpoint descriptors are filled with the correct information,bNumEmbMIDIJack and bLength are set incorrectly in these descriptors.This does not matter when the numbers of in and out ports are equal, butwhen they differ the host will receive broken descriptors withuninitialized stack memory leaking into the descriptor for whichevervalue is smaller.The precise meaning of "in" and "out" in the port counts is not clearlydefined and can be confusing. But elsewhere the driver consistentlyuses this to match the USB meaning of IN and OUT viewed from the host,so that "in" ports send data to the host and "out" ports receive datafrom it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21844 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Add check for next_buffer in receive_encrypted_standard()Add check for the return value of cifs_buf_get() and cifs_small_buf_get()in receive_encrypted_standard() to prevent null pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21846 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:acct: perform last write from workqueueIn [1] it was reported that the acct(2) system call can be used totrigger NULL deref in cases where it is set to write to a file thattriggers an internal lookup. This can e.g., happen when pointing acc(2)to /sys/power/resume. At the point the where the write to this filehappens the calling task has already exited and called exit_fs(). Alookup will thus trigger a NULL-deref when accessing current->fs.Reorganize the code so that the the final write happens from theworkqueue but with the caller's credentials. This preserves the(strange) permission model and has almost no regression risk.This api should stop to exist though.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21848 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()Add check for the return value of nfp_app_ctrl_msg_alloc() innfp_bpf_cmsg_alloc() to prevent null pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: avoid holding freeze_mutex during mmap operationWe use map->freeze_mutex to prevent races between map_freeze() andmemory mapping BPF map contents with writable permissions. The way wenaively do this means we'll hold freeze_mutex for entire duration of allthe mm and VMA manipulations, which is completely unnecessary. This canpotentially also lead to deadlocks, as reported by syzbot in [0].So, instead, hold freeze_mutex only during writeability checks, bump(proactively) "write active" count for the map, unlock the mutex andproceed with mmap logic. And only if something went wrong during mmaplogic, then undo that "write active" counter increment. [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21858 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:geneve: Fix use-after-free in geneve_find_dev().syzkaller reported a use-after-free in geneve_find_dev() [0]without repro.geneve_configure() links struct geneve_dev.next tonet_generic(net, geneve_net_id)->geneve_list.The net here could differ from dev_net(dev) if IFLA_NET_NS_PID,IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set.When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finallycalls unregister_netdevice_queue() for each dev in the netns,and later the dev is freed.However, its geneve_dev.next is still linked to the backend UDPsocket netns.Then, use-after-free will occur when another geneve dev is createdin the netns.Let's call geneve_dellink() instead in geneve_destroy_tunnels().[0]:BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline]BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3dHardware name: linux,dummy-virt (DT)Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21859 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: gadget: f_midi: f_midi_complete to call queue_workWhen using USB MIDI, a lock is attempted to be acquired twice through are-entrant call to f_midi_transmit, causing a deadlock.Fix it by using queue_work() to schedule the inner f_midi_transmit() viaa high priority work queue from the completion handler.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21861 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize()If migration succeeded, we calledfolio_migrate_flags()->mem_cgroup_migrate() to migrate the memcg from theold to the new folio. This will set memcg_data of the old folio to 0.Similarly, if migration failed, memcg_data of the dst folio is left unset.If we call folio_putback_lru() on such folios (memcg_data == 0), we willadd the folio to be freed to the LRU, making memcg code unhappy. Runningthe hmm selftests: # ./hmm-tests ... # RUN hmm.hmm_device_private.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.116547][T14893] ? __warn.cold+0x110/0x210 [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.118667][T14893] ? report_bug+0x1b9/0x320 [ 102.119571][T14893] ? handle_bug+0x54/0x90 [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50 [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20 [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dump_page+0x4f/0x60 [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200 [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720 [ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.129550][T14893] folio_putback_lru+0x16/0x80 [ 102.130564][T14893] migrate_device_finalize+0x9b/0x530 [ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80Likely, nothing else goes wrong: putting the last folio reference willremove the folio from the LRU again. So besides memcg complaining, addingthe folio to be freed to the LRU is just an unnecessary step.The new flow resembles what we have in migrate_folio_move(): add the dstto the lru, rem---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21862 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drop_monitor: fix incorrect initialization orderSyzkaller reports the following bug:BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7RIP: 0033:0x7f3f9815aee9Code: 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 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768If drop_monitor is built as a kernel module, syzkaller may have timeto send a netlink NET_DM_CMD_START message during the module loading.This will call the net_dm_monitor_start() function that usesa spinlock that has not yet been initialized.To fix this, let's place resource initialization above the registrationof a generic netlink family.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: prevent opcode speculationsqe->opcode is used for different tables, make sure we santitise itagainst speculations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21866 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOCErhard reported the following KASAN hit while booting his PowerMac G4with a KASAN-enabled kernel 6.13-rc6: BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293 CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] print_report+0xdc/0x504 [c2437610] [c050475c] kasan_report+0xf8/0x108 [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 [c24376c0] [c004c014] patch_instructions+0x15c/0x16c [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 CR: 24004422 XER: 00000000 GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00 The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: text_area_cpu_up+0x20/0x190 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ==================================================================f8 corresponds to KASAN_VMALLOC_INVALID which means the area is notinitialised hence not supposed to be used yet.Powerpc text patching infrastructure allocates a virtual memory areausing get_vm_area() and flags it as VM_ALLOC. But that flag is meantto be used for vmalloc() and vmalloc() allocated memory is notsupposed to be used before a call to __vmalloc_node_range() which isnever called for that area.That went undetected until commit e4137f08816b ("mm, kasan, kmsan:instrument copy_from/to_kernel_nofault")The area allocated by text_area_cpu_up() is not vmalloc memory, it ismapped directly on demand when needed by map_kernel_page(). There isno VM flag corresponding to such usage, so just pass no flag. That waythe area will be unpoisonned and usable immediately.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21871 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tee: optee: Fix supplicant wait loopOP-TEE supplicant is a user-space daemon and it's possible for itbe hung or crashed or killed in the middle of processing an OP-TEERPC call. It becomes more complicated when there is incorrect shutdownordering of the supplicant process vs the OP-TEE client application whichcan eventually lead to system hang-up waiting for the closure of theclient application.Allow the client process waiting in kernel for supplicant response tobe killed rather than indefinitely waiting in an unkillable state. Also,a normal uninterruptible wait should not have resulted in the hung-taskwatchdog getting triggered, but the endless loop would.This fixes issues observed during system reboot/shutdown when supplicantgot hung for some reason or gets crashed/killed which lead to clientgetting hung in an unkillable state. It in turn lead to system being inhung up state requiring hard power off/on to recover.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21872 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:efi: Don't map the entire mokvar table to determine its sizeCurrently, when validating the mokvar table, we (re)map the entire tableon each iteration of the loop, adding space as we discover new entries.If the table grows over a certain size, this fails due to limitations ofearly_memmap(), and we get a failure and traceback: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220 ... Call Trace: ? __early_ioremap+0xef/0x220 ? __warn.cold+0x93/0xfa ? __early_ioremap+0xef/0x220 ? report_bug+0xff/0x140 ? early_fixup_exception+0x5d/0xb0 ? early_idt_handler_common+0x2f/0x3a ? __early_ioremap+0xef/0x220 ? efi_mokvar_table_init+0xce/0x1d0 ? setup_arch+0x864/0xc10 ? start_kernel+0x6b/0xa10 ? x86_64_start_reservations+0x24/0x30 ? x86_64_start_kernel+0xed/0xf0 ? common_startup_64+0x13e/0x141 ---[ end trace 0000000000000000 ]--- mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.Mapping the entire structure isn't actually necessary, as we don't everneed more than one entry header mapped at once.Changes efi_mokvar_table_init() to only map each entry header, not theentire table, when determining the table size. Since we're not mappingany data past the variable name, it also changes the code to enforcethat each variable name is NUL terminated, rather than attempting toverify it in place.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21875 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: always handle address removal under msk socket lockSyzkaller reported a lockdep splat in the PM control path: WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:733 ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 ___sys_sendmsg net/socket.c:2627 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2659 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 RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088Indeed the PM can try to send a RM_ADDR over a msk without acquiringfirst the msk socket lock.The bugged code-path comes from an early optimization: when thereare no subflows, the PM should (usually) not send RM_ADDRnotifications.The above statement is incorrect, as without locks another processcould concur---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21877 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: gl620a: fix endpoint checking in genelink_bind()Syzbot reports [1] a warning in usb_submit_urb() triggered byinconsistencies between expected and actually present endpointsin gl620a driver. Since genelink_bind() does not properlyverify whether specified eps are in fact provided by the device,in this case, an artificially manufactured one, one may get amismatch.Fix the issue by resorting to a usbnet utility functionusbnet_get_endpoints(), usually reserved for this very problem.Check for endpoints and return early before proceeding further ifany are missing.[1] Syzbot report:usb 5-1: Manufacturer: syzusb 5-1: SerialNumber: syzusb 5-1: config 0 descriptor??gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ...------------[ cut here ]------------usb 5-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503Modules linked in:CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: mld mld_ifc_workRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503...Call Trace: usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21878 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: npcm: disable interrupt enable bit before devm_request_irqThe customer reports that there is a soft lockup issue related tothe i2c driver. After checking, the i2c module was doing a tx transferand the bmc machine reboots in the middle of the i2c transaction, the i2cmodule keeps the status without being reset.Due to such an i2c module status, the i2c irq handler keeps gettingtriggered since the i2c irq handler is registered in the kernel bootingprocess after the bmc machine is doing a warm rebooting.The continuous triggering is stopped by the soft lockup watchdog timer.Disable the interrupt enable bit in the i2c module before callingdevm_request_irq to fix this issue since the i2c relative status bitis read-only.Here is the soft lockup log.[ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1][ 28.183351] Modules linked in:[ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1[ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 28.208128] pc : __do_softirq+0xb0/0x368[ 28.212055] lr : __do_softirq+0x70/0x368[ 28.215972] sp : ffffff8035ebca00[ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780[ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0[ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b[ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff[ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000[ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2[ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250[ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434[ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198[ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40[ 28.290611] Call trace:[ 28.293052] __do_softirq+0xb0/0x368[ 28.296625] __irq_exit_rcu+0xe0/0x100[ 28.300374] irq_exit+0x14/0x20[ 28.303513] handle_domain_irq+0x68/0x90[ 28.307440] gic_handle_irq+0x78/0xb0[ 28.311098] call_on_irq_stack+0x20/0x38[ 28.315019] do_interrupt_handler+0x54/0x5c[ 28.319199] el1_interrupt+0x2c/0x4c[ 28.322777] el1h_64_irq_handler+0x14/0x20[ 28.326872] el1h_64_irq+0x74/0x78[ 28.330269] __setup_irq+0x454/0x780[ 28.333841] request_threaded_irq+0xd0/0x1b4[ 28.338107] devm_request_threaded_irq+0x84/0x100[ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0[ 28.346990] platform_probe+0x6c/0xc4[ 28.350653] really_probe+0xcc/0x45c[ 28.354227] __driver_probe_device+0x8c/0x160[ 28.358578] driver_probe_device+0x44/0xe0[ 28.362670] __driver_attach+0x124/0x1d0[ 28.366589] bus_for_each_dev+0x7c/0xe0[ 28.370426] driver_attach+0x28/0x30[ 28.373997] bus_add_driver+0x124/0x240[ 28.377830] driver_register+0x7c/0x124[ 28.381662] __platform_driver_register+0x2c/0x34[ 28.386362] npcm_i2c_init+0x3c/0x5c[ 28.389937] do_one_initcall+0x74/0x230[ 28.393768] kernel_init_freeable+0x24c/0x2b4[ 28.398126] kernel_init+0x28/0x130[ 28.401614] ret_from_fork+0x10/0x20[ 28.405189] Kernel panic - not syncing: softlockup: hung tasks[ 28.411011] SMP: stopping secondary CPUs[ 28.414933] Kernel Offset: disabled[ 28.418412] CPU features: 0x00000000,00000802[ 28.427644] Rebooting in 20 seconds..

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21885 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/bnxt_re: Fix the page details for the srq created by kernel consumersWhile using nvme target with use_srq on, below kernel panic is noticed.[ 549.698111] bnxt_en 0000:41:00.0 enp65s0np0: FEC autoneg off encoding: Clause 91 RS(544,514)[ 566.393619] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI..[ 566.393799] [ 566.393807] ? __die_body+0x1a/0x60[ 566.393823] ? die+0x38/0x60[ 566.393835] ? do_trap+0xe4/0x110[ 566.393847] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393867] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393881] ? do_error_trap+0x7c/0x120[ 566.393890] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393911] ? exc_divide_error+0x34/0x50[ 566.393923] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393939] ? asm_exc_divide_error+0x16/0x20[ 566.393966] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393997] bnxt_qplib_create_srq+0xc9/0x340 [bnxt_re][ 566.394040] bnxt_re_create_srq+0x335/0x3b0 [bnxt_re][ 566.394057] ? srso_return_thunk+0x5/0x5f[ 566.394068] ? __init_swait_queue_head+0x4a/0x60[ 566.394090] ib_create_srq_user+0xa7/0x150 [ib_core][ 566.394147] nvmet_rdma_queue_connect+0x7d0/0xbe0 [nvmet_rdma][ 566.394174] ? lock_release+0x22c/0x3f0[ 566.394187] ? srso_return_thunk+0x5/0x5fPage size and shift info is set only for the user space SRQs.Set page size and page shift for kernel space SRQs also.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21890 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix checksums set in idpf_rx_rsc()idpf_rx_rsc() uses skb_transport_offset(skb) while the transport headeris not set yet.This triggers the following warning for CONFIG_DEBUG_NET=y builds.DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb))[ 69.261620] WARNING: CPU: 7 PID: 0 at ./include/linux/skbuff.h:3020 idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261629] Modules linked in: vfat fat dummy bridge intel_uncore_frequency_tpmi intel_uncore_frequency_common intel_vsec_tpmi idpf intel_vsec cdc_ncm cdc_eem cdc_ether usbnet mii xhci_pci xhci_hcd ehci_pci ehci_hcd libeth[ 69.261644] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G S W 6.14.0-smp-DEV #1697[ 69.261648] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN[ 69.261650] RIP: 0010:idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261677] ? __warn (kernel/panic.c:242 kernel/panic.c:748)[ 69.261682] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261687] ? report_bug (lib/bug.c:?)[ 69.261690] ? handle_bug (arch/x86/kernel/traps.c:285)[ 69.261694] ? exc_invalid_op (arch/x86/kernel/traps.c:309)[ 69.261697] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)[ 69.261700] ? __pfx_idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:4011) idpf[ 69.261704] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261708] ? idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:3072) idpf[ 69.261712] __napi_poll (net/core/dev.c:7194)[ 69.261716] net_rx_action (net/core/dev.c:7265)[ 69.261718] ? __qdisc_run (net/sched/sch_generic.c:293)[ 69.261721] ? sched_clock (arch/x86/include/asm/preempt.h:84 arch/x86/kernel/tsc.c:288)[ 69.261726] handle_softirqs (kernel/softirq.c:561)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21891 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: ensure network headers are in skb linear partsyzbot found that ipvlan_process_v6_outbound() was assumingthe IPv6 network header isis present in skb->head [1]Add the needed pskb_network_may_pull() calls for bothIPv4 and IPv6 handlers.[1]BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 ipv6_addr_type include/net/ipv6.h:555 [inline] ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline] ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651 ip6_route_output include/net/ip6_route.h:93 [inline] ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476 ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline] ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671 ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223 __netdev_start_xmit include/linux/netdevice.h:5150 [inline] netdev_start_xmit include/linux/netdevice.h:5159 [inline] xmit_one net/core/dev.c:3735 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751 sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343 qdisc_restart net/sched/sch_generic.c:408 [inline] __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416 qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127 net_tx_action+0x78b/0x940 net/core/dev.c:5484 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611 dev_queue_xmit include/linux/netdevice.h:3311 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3132 [inline] packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164 sock_sendmsg_nosec net/socket.c:718 [inline]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21894 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: VFs do not support HWTSTAMP_TX_ONESTEP_SYNCActually ENETC VFs do not support HWTSTAMP_TX_ONESTEP_SYNC because onlyENETC PF can access PMa_SINGLE_STEP registers. And there will be a crashif VFs are used to test one-step timestamp, the crash log as follows.[ 129.110909] Unable to handle kernel paging request at virtual address 00000000000080c0[ 129.287769] Call trace:[ 129.290219] enetc_port_mac_wr+0x30/0xec (P)[ 129.294504] enetc_start_xmit+0xda4/0xe74[ 129.298525] enetc_xmit+0x70/0xec[ 129.301848] dev_hard_start_xmit+0x98/0x118

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21898 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Avoid potential division by zero in function_stat_show()Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64}produce zero and skip stddev computation in that case.For now don't care about rec->counter * rec->counter overflow becauserec->time * rec->time overflow will likely happen earlier.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix bad hist from corrupting named_triggers listThe following commands causes a crash: ~# cd /sys/kernel/tracing/events/rcu/rcu_callback ~# echo 'hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=bad:keys=common_pid' > triggerBecause the following occurs:event_trigger_write() { trigger_process_regex() { event_hist_trigger_parse() { data = event_trigger_alloc(..); event_trigger_register(.., data) { cmd_ops->reg(.., data, ..) [hist_register_trigger()] { data->ops->init() [event_hist_trigger_init()] { save_named_trigger(name, data) { list_add(&data->named_list, &named_triggers); } } } } ret = create_actions(); (return -EINVAL) if (ret) goto out_unreg;[..] ret = hist_trigger_enable(data, ...) { list_add_tail_rcu(&data->list, &file->triggers); <<<---- SKIPPED!!! (this is important!)[..] out_unreg: event_hist_unregister(.., data) { cmd_ops->unreg(.., data, ..) [hist_unregister_trigger()] { list_for_each_entry(iter, &file->triggers, list) { if (!hist_trigger_match(data, iter, named_data, false)) <- never matches continue; [..] test = iter; } if (test && test->ops->free) <<<-- test is NULL test->ops->free(test) [event_hist_trigger_free()] { [..] if (data->name) del_named_trigger(data) { list_del(&data->named_list); <<<<-- NEVER gets removed! } } } } [..] kfree(data); <<<-- frees item but it is still on listThe next time a hist with name is registered, it causes an u-a-f bug andthe kernel can crash.Move the code around such that if event_trigger_register() succeeds, thenext thing called is hist_trigger_enable() which adds it to the list.A bunch of actions is called if get_named_trigger_data() returns false.But that doesn't need to be called after event_trigger_register(), so itcan be moved up, allowing event_trigger_register() to be called justbefore hist_trigger_enable() keeping them together and allowing thefile->triggers to be properly populated.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21904 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:caif_virtio: fix wrong pointer check in cfv_probe()del_vqs() frees virtqueues, therefore cfv->vq_tx pointer should be checkedfor NULL before calling it, not cfv->vdev. Also the current implementationis redundant because the pointer cfv->vdev is dereferenced before it ischecked for NULL.Fix this by checking cfv->vq_tx for NULL instead of cfv->vdev beforecalling del_vqs().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21905 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: limit printed string from FW fileThere's no guarantee here that the file is always with aNUL-termination, so reading the string may read beyond theend of the TLV. If that's the last TLV in the file, it canperhaps even read beyond the end of the file buffer.Fix that by limiting the print format to the size of thebuffer we have.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21909 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: reject cooked mode if it is set along with other flagsIt is possible to set both MONITOR_FLAG_COOK_FRAMES and MONITOR_FLAG_ACTIVEflags simultaneously on the same monitor interface from the userspace. Thiscauses a sub-interface to be created with no IEEE80211_SDATA_IN_DRIVER bitset because the monitor interface is in the cooked state and it takesprecedence over all other states. When the interface is then being deletedthe kernel calls WARN_ONCE() from check_sdata_in_driver() because of missingthat bit.Fix this by rejecting MONITOR_FLAG_COOK_FRAMES if it is set along withother flags.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21910 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: regulatory: improve invalid hints checkingSyzbot keeps reporting an issue [1] that occurs when erroneous symbolssent from userspace get through into user_alpha2[] viaregulatory_hint_user() call. Such invalid regulatory hints should berejected.While a sanity check from commit 47caf685a685 ("cfg80211: regulatory:reject invalid hints") looks to be enough to deter these very cases,there is a way to get around it due to 2 reasons.1) The way isalpha() works, symbols other than latin lower andupper letters may be used to determine a country/domain.For instance, greek letters will also be considered upper/lowerletters and for such characters isalpha() will return true as well.However, ISO-3166-1 alpha2 codes should only hold latincharacters.2) While processing a user regulatory request, betweenreg_process_hint_user() and regulatory_hint_user() there happens tobe a call to queue_regulatory_request() which modifies letters inrequest->alpha2[] with toupper(). This works fine for latin symbols,less so for weird letter characters from the second part of _ctype[].Syzbot triggers a warning in is_user_regdom_saved() by first sendingover an unexpected non-latin letter that gets malformed by toupper()into a character that ends up failing isalpha() check.Prevent this by enhancing is_an_alpha2() to ensure that incomingsymbols are latin letters and nothing else.[1] Syzbot report:------------[ cut here ]------------Unexpected user alpha2: A�WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline]WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline]WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516Modules linked in:CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: events_power_efficient crda_timeout_workRIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline]RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline]RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516...Call Trace: crda_timeout_work+0x27/0x50 net/wireless/reg.c:542 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21914 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:slimbus: messaging: Free transaction ID in delayed interrupt scenarioIn case of interrupt delay for any reason, slim_do_transfer()returns timeout error but the transaction ID (TID) is not freed.This results into invalid memory access insideqcom_slim_ngd_rx_msgq_cb() due to invalid TID.Fix the issue by freeing the TID in slim_do_transfer() beforereturning timeout error to avoid invalid memory access.Call trace:__memcpy_fromio+0x20/0x190qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl]vchan_complete+0x2a0/0x4a0tasklet_action_common+0x274/0x700tasklet_action+0x28/0x3c_stext+0x188/0x620run_ksoftirqd+0x34/0x74smpboot_thread_fn+0x1d8/0x464kthread+0x178/0x238ret_from_fork+0x10/0x20Code: aa0003e8 91000429 f100044a 3940002b (3800150b)---[ end trace 0fe00bec2b975c99 ]---Kernel panic - not syncing: Oops: Fatal exception in interrupt.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21917 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: renesas_usbhs: Flush the notify_hotplug_workWhen performing continuous unbind/bind operations on the USB driversavailable on the Renesas RZ/G2L SoC, a kernel crash with the message"Unable to handle kernel NULL pointer dereference at virtual address"may occur. This issue points to the usbhsc_notify_hotplug() function.Flush the delayed work to avoid its execution when driver resources areunavailable.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21919 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/fair: Fix potential memory corruption in child_cfs_rq_on_listchild_cfs_rq_on_list attempts to convert a 'prev' pointer to a cfs_rq.This 'prev' pointer can originate from struct rq's leaf_cfs_rq_list,making the conversion invalid and potentially leading to memorycorruption. Depending on the relative positions of leaf_cfs_rq_list andthe task group (tg) pointer within the struct, this can cause a memoryfault or access garbage data.The issue arises in list_add_leaf_cfs_rq, where bothcfs_rq->leaf_cfs_rq_list and rq->leaf_cfs_rq_list are added to the sameleaf list. Also, rq->tmp_alone_branch can be set to rq->leaf_cfs_rq_list.This adds a check `if (prev == &rq->leaf_cfs_rq_list)` after the mainconditional in child_cfs_rq_on_list. This ensures that the container_ofoperation will convert a correct cfs_rq struct.This check is sufficient because only cfs_rqs on the same CPU are addedto the list, so verifying the 'prev' pointer against the current rq's listhead is enough.Fixes a potential memory corruption issue that due to current structlayout might not be manifesting as a crash but could lead to unpredictablebehavior when the layout changes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21920 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vlan: enforce underlying device typeCurrently, VLAN devices can be created on top of non-ethernet devices.Besides the fact that it doesn't make much sense, this also causes abug which leaks the address of a kernel function to usermode.When creating a VLAN device, we initialize GARP (garp_init_applicant)and MRP (mrp_init_applicant) for the underlying device.As part of the initialization process, we add the multicast address ofeach applicant to the underlying device, by calling dev_mc_add.__dev_mc_add uses dev->addr_len to determine the length of the newmulticast address.This causes an out-of-bounds read if dev->addr_len is greater than 6,since the multicast addresses provided by GARP and MRP are only 6bytes long.This behaviour can be reproduced using the following commands:ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev loip l set up dev gretestip link add link gretest name vlantest type vlan id 100Then, the following command will display the address of garp_pdu_rcv:ip maddr show | grep 01:80:c2:00:00:21Fix the bug by enforcing the type of the underlying device during VLANdevice initialization.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21924 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: make sure ptp clock is unregister and freed if hclge_ptp_get_cycle returns an errorDuring the initialization of ptp, hclge_ptp_get_cycle might return an errorand returned directly without unregister clock and free it. To avoid that,call hclge_ptp_destroy_clock to unregist and free clock ifhclge_ptp_get_cycle failed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21925 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:llc: do not use skb_get() before dev_queue_xmit()syzbot is able to crash hosts [1], using llc and devicesnot supporting IFF_TX_SKB_SHARING.In this case, e1000 driver calls eth_skb_pad(), whilethe skb is shared.Simply replace skb_get() by skb_clone() in net/llc/llc_s_ac.cNote that e1000 driver might have an issue with pktgen,because it does not clear IFF_TX_SKB_SHARING, this is anorthogonal change.We need to audit other skb_get() uses in net/llc.[1]kernel BUG at net/core/skbuff.c:2178 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskb_expand_head+0x6ce/0x1240 net/core/skbuff.c:2178Call Trace: __skb_pad+0x18a/0x610 net/core/skbuff.c:2466 __skb_put_padto include/linux/skbuff.h:3843 [inline] skb_put_padto include/linux/skbuff.h:3862 [inline] eth_skb_pad include/linux/etherdevice.h:656 [inline] e1000_xmit_frame+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000_main.c:3128 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3806 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3822 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:4045 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4621 dev_queue_xmit include/linux/netdevice.h:3313 [inline] llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x239/0x510 net/llc/llc_sap.c:209 llc_ui_sendmsg+0xd0d/0x14e0 net/llc/af_llc.c:993 sock_sendmsg_nosec net/socket.c:718 [inline]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21926 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: gso: fix ownership in __udp_gso_segmentIn __udp_gso_segment the skb destructor is removed before segmenting theskb but the socket reference is kept as-is. This is an issue if theoriginal skb is later orphaned as we can hit the following bug: kernel BUG at ./include/linux/skbuff.h:3312! (skb_orphan) RIP: 0010:ip_rcv_core+0x8b2/0xca0 Call Trace: ip_rcv+0xab/0x6e0 __netif_receive_skb_one_core+0x168/0x1b0 process_backlog+0x384/0x1100 __napi_poll.constprop.0+0xa1/0x370 net_rx_action+0x925/0xe50The above can happen following a sequence of events when usingOpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes anOVS_ACTION_ATTR_OUTPUT action:1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb goes through queue_gso_packets and then __udp_gso_segment, where its destructor is removed.2. The segments' data are copied and sent to userspace.3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the same original skb is sent to its path.4. If it later hits skb_orphan, we hit the bug.Fix this by also removing the reference to the socket in__udp_gso_segment.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21927 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()nvme_tcp_recv_pdu() doesn't check the validity of the header length.When header digests are enabled, a target might send a packet with aninvalid header length (e.g. 255), causing nvme_tcp_verify_hdgst()to access memory outside the allocated area and cause memory corruptionsby overwriting it with the calculated digest.Fix this by rejecting packets with an unexpected header length.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21928 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()The system can experience a random crash a few minutes after the driver isremoved. This issue occurs due to improper handling of memory freeing inthe ishtp_hid_remove() function.The function currently frees the `driver_data` directly within the loopthat destroys the HID devices, which can lead to accessing freed memory.Specifically, `hid_destroy_device()` uses `driver_data` when it calls`hid_ishtp_set_feature()` to power off the sensor, so freeing`driver_data` beforehand can result in accessing invalid memory.This patch resolves the issue by storing the `driver_data` in a temporaryvariable before calling `hid_destroy_device()`, and then freeing the`driver_data` after the device is destroyed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folioCommit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages tobe offlined) add page poison checks in do_migrate_range in order to makeoffline hwpoisoned page possible by introducing isolate_lru_page andtry_to_unmap for hwpoisoned page. However folio lock must be held beforecalling try_to_unmap. Add it to fix this problem.Warning will be produced if folio is not locked during unmap: ------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21934 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: fix an API misues when rio_add_net() failsrio_add_net() calls device_register() and fails when device_register()fails. Thus, put_device() should be used rather than kfree(). Add"mport->net = NULL;" to avoid a use after free issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21935 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: add check for rio_add_net() in rio_scan_alloc_net()The return value of rio_add_net() should be checked. If it fails,put_device() should be called to free the memory and give up the referenceinitialized in rio_add_net().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21941 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_paramsNull pointer dereference issue could occur when pipe_ctx->plane_stateis null. The fix adds a check to ensure 'pipe_ctx->plane_state' is notnull before accessing. This prevents a null pointer dereference.Found by code review.(cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21948 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: appleir: Fix potential NULL dereference at raw event handleSyzkaller reports a NULL pointer dereference issue in input_event().BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline]BUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]BUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline]BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395Read of size 8 at addr 0000000000000028 by task syz-executor199/2949CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #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+0x116/0x1f0 lib/dump_stack.c:120 kasan_report+0xd9/0x110 mm/kasan/report.c:602 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] is_event_supported drivers/input/input.c:67 [inline] input_event+0x42/0xa0 drivers/input/input.c:395 input_report_key include/linux/input.h:439 [inline] key_down drivers/hid/hid-appleir.c:159 [inline] appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232 __hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111 hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484 __usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734 dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993 __run_hrtimer kernel/time/hrtimer.c:1739 [inline] __hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803 hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820 handle_softirqs+0x206/0x8d0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xfa/0x160 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 __mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185 add_timer+0x62/0x90 kernel/time/timer.c:1295 schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98 usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645 usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784 hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794 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/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f This happens due to the malformed report items sent by the emulated devicewhich results in a report, that has no fields, being added to the report list.Due to this appleir_input_configured() is never called, hidinput_connect()fails which results in the HID_CLAIMED_INPUT flag is not being set. However,it does not make appleir_probe() fail and lets the event callback to becalled without the associated input device.Thus, add a check for the HID_CLAIMED_INPUT flag and leave the event hookearly if the driver didn't claim any input_dev for some reason. Moreover,some other hid drivers accessing input_dev in their event callbacks do havesimilar checks, too.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21950 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctlIn the "pmcmd_ioctl" function, three memory objects allocated bykmalloc are initialized by "hcall_get_cpu_state", which are thencopied to user space. The initializer is indeed implemented in"acrn_hypercall2" (arch/x86/include/asm/acrn.h). There is a risk ofinformation leakage due to uninitialized bytes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21951 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlockThere are multiple places from where the recovery work gets scheduledasynchronously. Also, there are multiple places where the caller waitssynchronously for the recovery to be completed. One such place is duringthe PM shutdown() callback.If the device is not alive during recovery_work, it will try to reset thedevice using pci_reset_function(). This function internally will take thedevice_lock() first before resetting the device. By this time, if the lockhas already been acquired, then recovery_work will get stalled whilewaiting for the lock. And if the lock was already acquired by the callerwhich waits for the recovery_work to be completed, it will lead todeadlock.This is what happened on the X1E80100 CRD device when the device diedbefore shutdown() callback. Driver core calls the driver's shutdown()callback while holding the device_lock() leading to deadlock.And this deadlock scenario can occur on other paths as well, like duringthe PM suspend() callback, where the driver core would hold thedevice_lock() before calling driver's suspend() callback. And if therecovery_work was already started, it could lead to deadlock. This is alsoobserved on the X1E80100 CRD.So to fix both issues, use pci_try_reset_function() in recovery_work. Thisfunction first checks for the availability of the device_lock() beforetrying to reset the device. If the lock is available, it will acquire itand reset the device. Otherwise, it will return -EAGAIN. If that happens,recovery_work will fail with the error message "Recovery failed" as notmuch could be done.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21953 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: cleanup mana struct after debugfs_remove()When on a MANA VM hibernation is triggered, as part of hibernate_snapshot(),mana_gd_suspend() and mana_gd_resume() are called. If during thismana_gd_resume(), a failure occurs with HWC creation, mana_port_debugfspointer does not get reinitialized and ends up pointing to older,cleaned-up dentry.Further in the hibernation path, as part of power_down(), mana_gd_shutdown()is triggered. This call, unaware of the failures in resume, tries to cleanupthe already cleaned up mana_port_debugfs value and hits the following bug:[ 191.359296] mana 7870:00:00.0: Shutdown was called[ 191.359918] BUG: kernel NULL pointer dereference, address: 0000000000000098[ 191.360584] #PF: supervisor write access in kernel mode[ 191.361125] #PF: error_code(0x0002) - not-present page[ 191.361727] PGD 1080ea067 P4D 0[ 191.362172] Oops: Oops: 0002 [#1] SMP NOPTI[ 191.362606] CPU: 11 UID: 0 PID: 1674 Comm: bash Not tainted 6.14.0-rc5+ #2[ 191.363292] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024[ 191.364124] RIP: 0010:down_write+0x19/0x50[ 191.364537] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb e8 de cd ff ff 31 c0 ba 01 00 00 00 48 0f b1 13 75 16 65 48 8b 05 88 24 4c 6a 48 89 43 08 48 8b 5d[ 191.365867] RSP: 0000:ff45fbe0c1c037b8 EFLAGS: 00010246[ 191.366350] RAX: 0000000000000000 RBX: 0000000000000098 RCX: ffffff8100000000[ 191.366951] RDX: 0000000000000001 RSI: 0000000000000064 RDI: 0000000000000098[ 191.367600] RBP: ff45fbe0c1c037c0 R08: 0000000000000000 R09: 0000000000000001[ 191.368225] R10: ff45fbe0d2b01000 R11: 0000000000000008 R12: 0000000000000000[ 191.368874] R13: 000000000000000b R14: ff43dc27509d67c0 R15: 0000000000000020[ 191.369549] FS: 00007dbc5001e740(0000) GS:ff43dc663f380000(0000) knlGS:0000000000000000[ 191.370213] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 191.370830] CR2: 0000000000000098 CR3: 0000000168e8e002 CR4: 0000000000b73ef0[ 191.371557] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 191.372192] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[ 191.372906] Call Trace:[ 191.373262] [ 191.373621] ? show_regs+0x64/0x70[ 191.374040] ? __die+0x24/0x70[ 191.374468] ? page_fault_oops+0x290/0x5b0[ 191.374875] ? do_user_addr_fault+0x448/0x800[ 191.375357] ? exc_page_fault+0x7a/0x160[ 191.375971] ? asm_exc_page_fault+0x27/0x30[ 191.376416] ? down_write+0x19/0x50[ 191.376832] ? down_write+0x12/0x50[ 191.377232] simple_recursive_removal+0x4a/0x2a0[ 191.377679] ? __pfx_remove_one+0x10/0x10[ 191.378088] debugfs_remove+0x44/0x70[ 191.378530] mana_detach+0x17c/0x4f0[ 191.378950] ? __flush_work+0x1e2/0x3b0[ 191.379362] ? __cond_resched+0x1a/0x50[ 191.379787] mana_remove+0xf2/0x1a0[ 191.380193] mana_gd_shutdown+0x3b/0x70[ 191.380642] pci_device_shutdown+0x3a/0x80[ 191.381063] device_shutdown+0x13e/0x230[ 191.381480] kernel_power_off+0x35/0x80[ 191.381890] hibernate+0x3c6/0x470[ 191.382312] state_store+0xcb/0xd0[ 191.382734] kobj_attr_store+0x12/0x30[ 191.383211] sysfs_kf_write+0x3e/0x50[ 191.383640] kernfs_fop_write_iter+0x140/0x1d0[ 191.384106] vfs_write+0x271/0x440[ 191.384521] ksys_write+0x72/0xf0[ 191.384924] __x64_sys_write+0x19/0x20[ 191.385313] x64_sys_call+0x2b0/0x20b0[ 191.385736] do_syscall_64+0x79/0x150[ 191.386146] ? __mod_memcg_lruvec_state+0xe7/0x240[ 191.386676] ? __lruvec_stat_mod_folio+0x79/0xb0[ 191.387124] ? __pfx_lru_add+0x10/0x10[ 191.387515] ? queued_spin_unlock+0x9/0x10[ 191.387937] ? do_anonymous_page+0x33c/0xa00[ 191.388374] ? __handle_mm_fault+0xcf3/0x1210[ 191.388805] ? __count_memcg_events+0xbe/0x180[ 191.389235] ? handle_mm_fault+0xae/0x300[ 19---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21963 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing acdirmax mount optionUser-provided mount parameter acdirmax of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21964 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing acregmax mount optionUser-provided mount parameter acregmax of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21968 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix slab-use-after-free on hdcp_work[Why]A slab-use-after-free is reported when HDCP is destroyed but theproperty_validate_dwork queue is still running.[How]Cancel the delayed work when destroying workqueue.(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21969 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmdAfter the hci sync command releases l2cap_conn, the hci receive data workqueue references the released l2cap_conn when sending to the upper layer.Add hci dev lock to the hci receive data work queue to synchronize the two.[1]BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: hci1 hci_rx_workCall 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 l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline] l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline] l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817 hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline] hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5837: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860 l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726 hci_event_func net/bluetooth/hci_event.c:7473 [inline] hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525 hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244Freed by task 54: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266 hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21970 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Bridge, fix the crash caused by LAG state checkWhen removing LAG device from bridge, NETDEV_CHANGEUPPER event istriggered. Driver finds the lower devices (PFs) to flush all theoffloaded entries. And mlx5_lag_is_shared_fdb is checked, it returnsfalse if one of PF is unloaded. In such case,mlx5_esw_bridge_lag_rep_get() and its caller return NULL, instead ofthe alive PF, and the flush is skipped.Besides, the bridge fdb entry's lastuse is updated in mlx5 bridgeevent handler. But this SWITCHDEV_FDB_ADD_TO_BRIDGE event can beignored in this case because the upper interface for bond is deleted,and the entry will never be aged because lastuse is never updated.To make things worse, as the entry is alive, mlx5 bridge workqueuekeeps sending that event, which is then handled by kernel bridgenotifier. It causes the following crash when accessing the passed bondnetdev which is already destroyed.To fix this issue, remove such checks. LAG state is already checked incommit 15f8f168952f ("net/mlx5: Bridge, verify LAG state when addingbond to bridge"), driver still need to skip offload if LAG becomesinvalid state after initialization. Oops: stack segment: 0000 [#1] SMP CPU: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Tainted: G OE 6.11.0_mlnx #1 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_bridge_wq mlx5_esw_bridge_update_work [mlx5_core] RIP: 0010:br_switchdev_event+0x2c/0x110 [bridge] Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 <4c> 8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7 RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297 RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0 RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60 R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __die_body+0x1a/0x60 ? die+0x38/0x60 ? do_trap+0x10b/0x120 ? do_error_trap+0x64/0xa0 ? exc_stack_segment+0x33/0x50 ? asm_exc_stack_segment+0x22/0x30 ? br_switchdev_event+0x2c/0x110 [bridge] ? sched_balance_newidle.isra.149+0x248/0x390 notifier_call_chain+0x4b/0xa0 atomic_notifier_call_chain+0x16/0x20 mlx5_esw_bridge_update+0xec/0x170 [mlx5_core] mlx5_esw_bridge_update_work+0x19/0x40 [mlx5_core] process_scheduled_works+0x81/0x390 worker_thread+0x106/0x250 ? bh_worker+0x110/0x110 kthread+0xb7/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21975 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: handle errors in mlx5_chains_create_table()In mlx5_chains_create_table(), the return value of mlx5_get_fdb_sub_ns()and mlx5_get_flow_namespace() must be checked to prevent NULL pointerdereferences. If either function fails, the function should log errormessage with mlx5_core_warn() and return error pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21978 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/hyperv: Fix address space leak when Hyper-V DRM device is removedWhen a Hyper-V DRM device is probed, the driver allocates MMIO space forthe vram, and maps it cacheable. If the device removed, or in the errorpath for device probing, the MMIO space is released but no unmap is done.Consequently the kernel address space for the mapping is leaked.Fix this by adding iounmap() calls in the device removal path, and in theerror path during device probing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21980 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched: address a potential NULL pointer dereference in the GRED scheduler.If kzalloc in gred_init returns a NULL pointer, the code follows theerror handling path, invoking gred_destroy. This, in turn, callsgred_offload, where memset could receive a NULL pointer as input,potentially leading to a kernel crash.When table->opt is NULL in gred_init(), gred_change_table_def()is not called yet, so it is not necessary to call ->ndo_setup_tc()in gred_offload().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21991 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst: "Some memory may share the same node as a CPU, and others are provided as memory only nodes."Therefore, some node CPU masks may be empty and wouldn't have a "first CPU".On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat: UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type 'unsigned long[512]' [...] Call Trace: dump_stack __ubsan_handle_out_of_bounds load_microcode_amd request_microcode_amd reload_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update. [ bp: Massage commit message, fix typo. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21992 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: ignore non-functional sensor in HP 5MP CameraThe HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface thatis not actually implemented. Attempting to access this non-functionalsensor via iio_info causes system hangs as runtime PM tries to wake upan unresponsive sensor. [453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff [453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffffAdd this device to the HID ignore list since the sensor interface isnon-functional by design and should not be exposed to userspace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21993 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()When performing an iSCSI boot using IPv6, iscsistart still reads the/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefixlength is 64, this causes the shift exponent to become negative,triggering a UBSAN warning. As the concept of a subnet mask does notapply to IPv6, the value is set to ~0 to suppress the warning message.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-21996 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()On the off chance that command stream passed from userspace viaioctl() call to radeon_vce_cs_parse() is weirdly crafted andfirst command to execute is to encode (case 0x03000001), the functionin question will attempt to call radeon_vce_cs_reloc() with sizeargument that has not been properly initialized. Specifically, 'size'will point to 'tmp' variable before the latter had a chance to beassigned any value.Play it safe and init 'tmp' with 0, thus ensuring thatradeon_vce_cs_reloc() will catch an early error in cases like these.Found by Linux Verification Center (linuxtesting.org) with staticanalysis tool SVACE.(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22003 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: ucan: fix out of bound read in strscpy() sourceCommit 7fdaf8966aae ("can: ucan: use strscpy() to instead of strncpy()")unintentionally introduced a one byte out of bound read on strscpy()'ssource argument (which is kind of ironic knowing that strscpy() is meantto be a more secure alternative :)).Let's consider below buffers: dest[len + 1]; /* will be NUL terminated */ src[len]; /* may not be NUL terminated */When doing: strncpy(dest, src, len); dest[len] = '\0';strncpy() will read up to len bytes from src.On the other hand: strscpy(dest, src, len + 1);will read up to len + 1 bytes from src, that is to say, an out of boundread of one byte will occur on src if it is not NUL terminated. Notethat the src[len] byte is never copied, but strscpy() still needs toread it to check whether a truncation occurred or not.This exact pattern happened in ucan.The root cause is that the source is not NUL terminated. Instead ofdoing a copy in a local buffer, directly NUL terminate it as soon asusb_control_msg() returns. With this, the local firmware_str[] variablecan be removed.On top of this do a couple refactors: - ucan_ctl_payload->raw is only used for the firmware string, so rename it to ucan_ctl_payload->fw_str and change its type from u8 to char. - ucan_device_request_in() is only used to retrieve the firmware string, so rename it to ucan_get_fw_str() and refactor it to make it directly handle all the string termination logic.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22005 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everythingwhen it fails.Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh")moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output incase it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in theerror path.Note that we can remove the fib6_nh_release() call in nh_create_ipv6()later in net-next.git.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22007 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix error code in chan_alloc_skb_cb()The chan_alloc_skb_cb() function is supposed to return error pointers onerror. Returning NULL will lead to a NULL dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22008 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:regulator: check that dummy regulator has been probed before using itDue to asynchronous driver probing there is a chance that the dummyregulator hasn't already been probed when first accessing it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22010 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix soft lockup during bt pages loopDriver runs a for-loop when allocating bt pages and mapping them withbuffer pages. When a large buffer (e.g. MR over 100GB) is being allocated,it may require a considerable loop count. This will lead to soft lockup: watchdog: BUG: soft lockup - CPU#27 stuck for 22s! ... Call trace: hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2] hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2] hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2] alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2] hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x118/0x290 watchdog: BUG: soft lockup - CPU#35 stuck for 23s! ... Call trace: hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2] mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2] hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2] alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2] hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x120/0x2bcAdd a cond_resched() to fix soft lockup during these loops. In order notto affect the allocation performance of normal-size buffer, set the loopcount of a 100GB MR as the threshold to call cond_resched().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22014 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: pdr: Fix the potential deadlockWhen some client process A call pdr_add_lookup() to add the look up forthe service and does schedule locator work, later a process B got a newserver packet indicating locator is up and call pdr_locator_new_server()which eventually sets pdr->locator_init_complete to true which process Asees and takes list lock and queries domain list but it will timeout dueto deadlock as the response will queued to the same qmi->wq and it isordered workqueue and process B is not able to complete new serverrequest work due to deadlock on list lock.Fix it by removing the unnecessary list iteration as the list iterationis already being done inside locator work, so avoid it here and justcall schedule_work() here. Process A Process B process_scheduled_works()pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s get domain list txn wait failed: %d\n", req->service_name, ret);Timeout error log due to deadlock:" PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110"Thanks to Bjorn and Johan for letting me know that this commit also fixesan audio regression when using the in-kernel pd-mapper as that makes iteasier to hit this race. [1]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22018 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: Fix NULL pointer dereferenceWhen MPOA_cache_impos_rcvd() receives the msg, it can triggerNull Pointer Dereference Vulnerability if both entry andholding_time are NULL. Because there is only for the situationwhere entry is NULL and holding_time exists, it can be passedwhen both entry and holding_time are NULL. If these are NULL,the entry will be passd to eg_cache_put() as parameter andit is referenced by entry->use code in it.kasan log:[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037][ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0[ 3.326430] Call Trace:[ 3.326725] [ 3.326927] ? die_addr+0x3c/0xa0[ 3.327330] ? exc_general_protection+0x161/0x2a0[ 3.327662] ? asm_exc_general_protection+0x26/0x30[ 3.328214] ? vprintk_emit+0x15e/0x420[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10[ 3.329664] ? console_unlock+0x107/0x1d0[ 3.329946] ? __pfx_console_unlock+0x10/0x10[ 3.330283] ? do_syscall_64+0xa6/0x1a0[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10[ 3.331395] ? down_trylock+0x52/0x80[ 3.331703] ? vprintk_emit+0x15e/0x420[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10[ 3.332279] ? down_trylock+0x52/0x80[ 3.332527] ? _printk+0xbf/0x100[ 3.332762] ? __pfx__printk+0x10/0x10[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10[ 3.333614] msg_from_mpoad+0x1185/0x2750[ 3.333893] ? __build_skb_around+0x27b/0x3a0[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10[ 3.334501] ? __alloc_skb+0x1c0/0x310[ 3.334809] ? __pfx___alloc_skb+0x10/0x10[ 3.335283] ? _raw_spin_lock+0xe0/0xe0[ 3.335632] ? finish_wait+0x8d/0x1e0[ 3.335975] vcc_sendmsg+0x684/0xba0[ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10[ 3.337056] ? fdget+0x176/0x3e0[ 3.337348] __sys_sendto+0x4a2/0x510[ 3.337663] ? __pfx___sys_sendto+0x10/0x10[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400[ 3.338364] ? sock_ioctl+0x1bb/0x5a0[ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10[ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10[ 3.339727] ? selinux_file_ioctl+0xa4/0x260[ 3.340166] __x64_sys_sendto+0xe0/0x1c0[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140[ 3.340898] do_syscall_64+0xa6/0x1a0[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 3.341533] RIP: 0033:0x44a380[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00[ ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22028 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: vimc: skip .s_stream() for stopped entitiesSyzbot reported [1] a warning prompted by a check in call_s_stream()that checks whether .s_stream() operation is warranted for unstartedor stopped subdevs.Add a simple fix in vimc_streamer_pipeline_terminate() ensuring thatentities skip a call to .s_stream() unless they have been previouslyproperly started.[1] Syzbot report:------------[ cut here ]------------WARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460Modules linked in:CPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0...Call Trace: vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62 vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline] vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203 vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256 vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789 vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348 vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline] vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118 __video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122 video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463 v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366 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/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f2b85c01b19...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22044 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:acpi: nfit: fix narrowing conversion in acpi_nfit_ctlSyzkaller has reported a warning in to_nfit_bus_uuid(): "only secondarybus families can be translated". This warning is emited if the argumentis equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() firstverifies that a user-provided value call_pkg->nd_family of type u64 isnot equal to 0. Then the value is converted to int, and only after thatis compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalidargument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, whilethe lower 32 bits are zero.Furthermore, it is best to return EINVAL immediately upon seeing theinvalid user input. The WARNING is insufficient to prevent furtherundefined behavior based on other invalid user input.All checks of the input value should be applied to the original variablecall_pkg->nd_family.[iweiny: update commit message]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22053 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ibmveth: make veth_pool_store stop hangingv2:- Created a single error handling unlock and exit in veth_pool_store- Greatly expanded commit message with previous explanatory-only textSummary: Use rtnl_mutex to synchronize veth_pool_store with itself,ibmveth_close and ibmveth_open, preventing multiple calls in a row tonapi_disable.Background: Two (or more) threads could call veth_pool_store throughwriting to /sys/devices/vio/30000002/pool*/*. You can do this easilywith a little shell script. This causes a hang.I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a newkernel. I ran this test again and saw: Setting pool0/active to 0 Setting pool1/active to 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting Setting pool1/active to 1 Setting pool1/active to 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds. [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000 [ 243.683852][ T123] Call Trace: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0 [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60 [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ... [ 243.684087][ T123] Showing all locks held in the system: [ 243.684095][ T123] 1 lock held by khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248 [ 243.684114][ T123] 4 locks held by stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60 [ 243.684166][ T123] 5 locks held by stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22062 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: add mutual exclusion in proc_sctp_do_udp_port()We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start()or risk a crash as syzbot reported:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653Call Trace: udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 do_splice_from fs/splice.c:935 [inline] direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 do_splice_direct_actor fs/splice.c:1201 [inline] do_splice_direct+0x174/0x240 fs/splice.c:1227 do_sendfile+0xafd/0xe50 fs/read_write.c:1368 __do_sys_sendfile64 fs/read_write.c:1429 [inline] __se_sys_sendfile64 fs/read_write.c:1415 [inline] __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22066 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: imx-card: Add NULL check in imx_card_probe()devm_kasprintf() returns NULL when memory allocation fails. Currently,imx_card_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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22072 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spufs: fix gang directory lifetimesprior to "[POWERPC] spufs: Fix gang destroy leaks" we used to havea problem with gang lifetimes - creation of a gang returns openedgang directory, which normally gets removed when that gets closed,but if somebody has created a context belonging to that gang andkept it alive until the gang got closed, removal failed and weended up with a leak.Unfortunately, it had been fixed the wrong way. Dentry of gangdirectory was no longer pinned, and rmdir on close was gone.One problem was that failure of open kept calling simple_rmdir()as cleanup, which meant an unbalanced dput(). Another bug wasin the success case - gang creation incremented link count onroot directory, but that was no longer undone when gang gotdestroyed.Fix consists of * reverting the commit in question * adding a counter to gang, protected by ->i_rwsemof gang directory inode. * having it set to 1 at creation time, droppedin both spufs_dir_close() and spufs_gang_close() and bumpedin spufs_create_context(), provided that it's not 0. * using simple_recursive_removal() to take the gangdirectory out when counter reaches zero.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22075 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rtnetlink: Allocate vfinfo size for VF GUIDs when supportedCommit 30aad41721e0 ("net/core: Add support for getting VF GUIDs")added support for getting VF port and node GUIDs in netlink ifinfomessages, but their size was not taken into consideration in thefunction that allocates the netlink message, causing the followingwarning when a netlink message is filled with many VF port and nodeGUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too longKernel warning: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfx___mutex_lock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx___netlink_lookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? __pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ____sys_sendmsg+0x559/0x5a0 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 ___sys_sendmsg+0xe4/0x150 ? __pfx____sys_sendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? __pfx_handle_pte_fault+0x10/0x10---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22083 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpointIf vhost_scsi_set_endpoint is called multiple times without avhost_scsi_clear_endpoint between them, we can hit multiple bugsfound by Haoran Zhang:1. Use-after-free when no tpgs are found:This fixes a use after free that occurs when vhost_scsi_set_endpoint iscalled more than once and calls after the first call do not find anytpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first findstpgs to add to the vs_tpg array match=true, so we will do:vhost_vq_set_backend(vq, vs_tpg);...kfree(vs->vs_tpg);vs->vs_tpg = vs_tpg;If vhost_scsi_set_endpoint is called again and no tpgs are foundmatch=false so we skip the vhost_vq_set_backend call leaving thepointer to the vs_tpg we then free via:kfree(vs->vs_tpg);vs->vs_tpg = vs_tpg;If a scsi request is then sent we do:vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backendwhich sees the vs_tpg we just did a kfree on.2. Tpg dir removal hang:This patch fixes an issue where we cannot remove a LIO/target layertpg (and structs above it like the target) dir due to the refcountdropping to -1.The problem is that if vhost_scsi_set_endpoint detects a tpg is alreadyin the vs->vs_tpg array or if the tpg has been removed sotarget_depend_item fails, the undepend goto handler will dotarget_undepend_item on all tpgs in the vs_tpg array dropping theirrefcount to 0. At this time vs_tpg contains both the tpgs we have addedin the current vhost_scsi_set_endpoint call as well as tpgs we added inprevious calls which are also in vs->vs_tpg.Later, when vhost_scsi_clear_endpoint runs it will dotarget_undepend_item on all the tpgs in the vs->vs_tpg which will droptheir refcount to -1. Userspace will then not be able to remove the tpgand will hang when it tries to do rmdir on the tpg dir.3. Tpg leak:This fixes a bug where we can leak tpgs and cause them to beun-removable because the target name is overwritten whenvhost_scsi_set_endpoint is called multiple times but with differenttarget names.The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setupa vhost-scsi device to target/tpg mapping, then callsVHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs wehaven't seen before (target1 has tpg1 but target2 has tpg2). When thishappens we don't teardown the old target tpg mapping and just overwritethe target name and the vs->vs_tpg array. Later when we dovhost_scsi_clear_endpoint, we are passed in either target1 or target2'sname and we will only match that target's tpgs when we loop over thevs->vs_tpg. We will then return from the function without doingtarget_undepend_item on the tpgs.Because of all these bugs, it looks like being able to callvhost_scsi_set_endpoint multiple times was never supported. The majoruser, QEMU, already has checks to prevent this use case. So to fix theissues, this patch prevents vhost_scsi_set_endpoint from being calledif it's already successfully added tpgs. To add, remove or change thetpg config or target name, you must do a vhost_scsi_clear_endpointfirst.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22086 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flowWhen cur_qp isn't NULL, in order to avoid fetching the QP fromthe radix tree again we check if the next cqe QP is identical tothe one we already have.The bug however is that we are checking if the QP is identical bychecking the QP number inside the CQE against the QP number inside themlx5_ib_qp, but that's wrong since the QP number from the CQE is fromFW so it should be matched against mlx5_core_qp which is our FW QPnumber.Otherwise we could use the wrong QP when handling a CQE which couldcause the kernel trace below.This issue is mainly noticeable over QPs 0 & 1, since for now they arethe only QPs in our driver whereas the QP number inside mlx5_ib_qpdoesn't match the QP number inside mlx5_core_qp.BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()If track_pfn_copy() fails, we already added the dst VMA to the mapletree. As fork() fails, we'll cleanup the maple tree, and stumble overthe dst VMA for which we neither performed any reservation nor copiedany page tables.Consequently untrack_pfn() will see VM_PAT and try obtaining thePAT information from the page table -- which fails because the pagetable was not copied.The easiest fix would be to simply clear the VM_PAT flag of the dst VMAif track_pfn_copy() fails. However, the whole thing is about "simply"clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy()and performed a reservation, but copying the page tables fails, we'llsimply clear the VM_PAT flag, not properly undoing the reservation ...which is also wrong.So let's fix it properly: set the VM_PAT flag only if the reservationsucceeded (leaving it clear initially), and undo the reservation ifanything goes wrong while copying the page tables: clearing the VM_PATflag after undoing the reservation.Note that any copied page table entries will get zapped when the VMA willget removed later, after copy_page_range() succeeded; as VM_PAT is not setthen, we won't try cleaning VM_PAT up once more and untrack_pfn() will behappy. Note that leaving these page tables in place without a reservationis not a problem, as we are aborting fork(); this process will never run.A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Call Trace: ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180Likely this case was missed in: d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed")... and instead of undoing the reservation we simply cleared the VM_PAT flag.Keep the documentation of these functions in include/linux/pgtable.h,one place is more than sufficient -- we should clean that up for the otherfunctions like track_pfn_remap/untrack_pfn separately.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22109 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: Remove broken autobindBinding AX25 socket by using the autobind feature leads to memory leaksin ax25_connect() and also refcount leaks in ax25_release(). Memoryleak was detected with kmemleak:================================================================unreferenced object 0xffff8880253cd680 (size 96):backtrace:__kmalloc_node_track_caller_noprof (./include/linux/kmemleak.h:43)kmemdup_noprof (mm/util.c:136)ax25_rt_autobind (net/ax25/ax25_route.c:428)ax25_connect (net/ax25/af_ax25.c:1282)__sys_connect_file (net/socket.c:2045)__sys_connect (net/socket.c:2064)__x64_sys_connect (net/socket.c:2067)do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)================================================================When socket is bound, refcounts must be incremented the way it is donein ax25_bind() and ax25_setsockopt() (SO_BINDTODEVICE). In case ofautobind, the refcounts are not incremented.This bug leads to the following issue reported by Syzkaller:================================================================ax25_connect(): syz-executor318 uses autobind, please contact jreuter@yaina.de------------[ cut here ]------------refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 0 PID: 5317 at lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31Modules linked in:CPU: 0 UID: 0 PID: 5317 Comm: syz-executor318 Not tainted 6.14.0-rc4-syzkaller-00278-gece144f151ac #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31...Call Trace: __refcount_dec include/linux/refcount.h:336 [inline] refcount_dec include/linux/refcount.h:351 [inline] ref_tracker_free+0x6af/0x7e0 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4302 [inline] netdev_put include/linux/netdevice.h:4319 [inline] ax25_release+0x368/0x960 net/ax25/af_ax25.c:1080 __sock_release net/socket.c:647 [inline] sock_close+0xbc/0x240 net/socket.c:1398 __fput+0x3e9/0x9f0 fs/file_table.c:464 __do_sys_close fs/open.c:1580 [inline] __se_sys_close fs/open.c:1565 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1565 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 ... ================================================================Considering the issues above and the comments left in the code that say:"check if we can remove this feature. It is broken."; "autobinding in thismay or may not work"; - it is better to completely remove this feature thanto fix it because it is broken and leads to various kinds of memory bugs.Now calling connect() without first binding socket will result in anerror (-EINVAL). Userspace software that relies on the autobind featuremight get broken. However, this feature does not seem widely used withthis specific driver as it was not reliable at any point of time, and itis already broken anyway. E.g. ax25-tools and ax25-apps packages forpopular distributions do not use the autobind feature for AF_AX25.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22121 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()There's issue as follows:BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172CPU: 3 PID: 15172 Comm: syz-executor.0Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffAbove issue happens as ext4_xattr_delete_inode() isn't check xattris valid if xattr is in inode.To solve above issue call xattr_check_inode() check if xattr if validin inode. In fact, we can directly verify in ext4_iget_extra_inode(),so that there is no divergent verification.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-22125 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid1,raid10: don't ignore IO flagsIf blk-wbt is enabled by default, it's found that raid write performanceis quite bad because all IO are throttled by wbt of underlying disks,due to flag REQ_IDLE is ignored. And turns out this behaviour exist sinceblk-wbt is introduced.Other than REQ_IDLE, other flags should not be ignored as well, forexample REQ_META can be set for filesystems, clearing it can cause priorityreverse problems; And REQ_NOWAIT should not be cleared as well, becauseio will wait instead of failing directly in underlying disks.Fix those problems by keep IO flags from master bio.Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23131 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dlm: prevent NPD when writing a positive value to event_donedo_uevent returns the value written to event_done. In case it is apositive value, new_lockspace would undo all the work, and lockspacewould not be set. __dlm_new_lockspace, however, would treat thatpositive value as a success due to commit 8511a2728ab8 ("dlm: fix usecount with multiple joins").Down the line, device_create_lockspace would pass that NULL lockspace todlm_find_lockspace_local, leading to a NULL pointer dereference.Treating such positive values as successes prevents the problem. Giventhis has been broken for so long, this is unlikely to break userspaceexpectations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23136 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: int340x: Add NULL check for adevNot all devices have an ACPI companion fwnode, so adev might be NULL.This is similar to the commit cd2fd6eab480("platform/x86: int3472: Check for adev == NULL").Add a check for adev not being set and return -ENODEV in that case toavoid a possible NULL pointer deref in int3402_thermal_probe().Note, under the same directory, int3400_thermal_probe() has such acheck.[ rjw: Subject edit, added Fixes: ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23140 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq errorAfter devm_request_irq() fails with error in pci_endpoint_test_request_irq(),the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQshave been released.However, some requested IRQs remain unreleased, so there are still/proc/irq/* entries remaining, and this results in WARN() with thefollowing message: remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0' WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19cTo solve this issue, set the number of remaining IRQs to test->num_irqs,and release IRQs in advance by calling pci_endpoint_test_release_irq().[kwilczynski: commit log]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23142 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: detect and prevent references to a freed transport in sendmsgsctp_sendmsg() re-uses associations and transports when possible bydoing a lookup based on the socket endpoint and the message destinationaddress, and then sctp_sendmsg_to_asoc() sets the selected transport inall the message chunks to be sent.There's a possible race condition if another thread triggers the removalof that selected transport, for instance, by explicitly unbinding anaddress with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks havebeen set up and before the message is sent. This can happen if the sendbuffer is full, during the period when the sender thread temporarilyreleases the socket lock in sctp_wait_for_sndbuf().This causes the access to the transport data insctp_outq_select_transport(), when the association outqueue is flushed,to result in a use-after-free read.This change avoids this scenario by having sctp_transport_free() signalthe freeing of the transport, tagging it as "dead". In order to do this,the patch restores the "dead" bit in struct sctp_transport, which wasremoved incommit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").Then, in the scenario where the sender thread has released the socketlock in sctp_wait_for_sndbuf(), the bit is checked again afterre-acquiring the socket lock to detect the deletion. This is done whileholding a reference to the transport to prevent it from being freed inthe process.If the transport was deleted while the socket lock was relinquished,sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry thesend.The bug was found by a private syzbot instance (see the error report [1]and the C reproducer that triggers it [2]).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23143 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.When I ran the repro [0] and waited a few seconds, I observed twoLOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]Reproduction Steps: 1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables ruleAt step 3), the CIFS module calls sock_release() for the underlyingTCP socket, and it returns quickly. However, the socket remains inFIN_WAIT_1 because incoming FIN packets are dropped.At this point, the module's refcnt is 0 while the socket is stillalive, so the following rmmod command succeeds. # ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep cifs cifs 1159168 0This highlights a discrepancy between the lifetime of the CIFS moduleand the underlying TCP socket. Even after CIFS calls sock_release()and it returns, the TCP socket does not die immediately in order toclose the connection gracefully.While this is generally fine, it causes an issue with LOCKDEP becauseCIFS assigns a different lock class to the TCP socket's sk->sk_lockusing sock_lock_init_class_and_name().Once an incoming packet is processed for the socket or a timer fires,sk->sk_lock is acquired.Then, LOCKDEP checks the lock context in check_wait_context(), wherehlock_class() is called to retrieve the lock class. However, sincethe module has already been unloaded, hlock_class() logs a warningand returns NULL, triggering the null-ptr-deref.If LOCKDEP is enabled, we must ensure that a module callingsock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloadedwhile such a socket is still alive to prevent this issue.Let's hold the module reference in sock_lock_init_class_and_name()and release it when the socket is freed in sk_prot_free().Note that sock_lock_init() clears sk->sk_owner for svc_create_socket()that calls sock_lock_init_class_and_name() for a listening socket,which clones a socket by sk_clone_lock() without GFP_ZERO.[0]:CIFS_SERVER="10.0.0.137"CIFS_PATH="//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST"DEV="enp0s3"CRED="/root/WindowsCredential.txt"MNT=$(mktemp -d /tmp/XXXXXX)mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1iptables -A INPUT -s ${CIFS_SERVER} -j DROPfor i in $(seq 10);do umount ${MNT} rmmod cifs sleep 1donerm -r ${MNT}iptables -D INPUT -s ${CIFS_SERVER} -j DROP[1]:DEBUG_LOCKS_WARN_ON(1)WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs]CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)...Call Trace: __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350)...BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 0Oops: Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36Tainted: [W]=WARNHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:__lock_acquire (kernel/---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23144 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ...Indeed, led_sysfs_enable() has to be called with the led_accesslock held.Hold the lock when calling led_sysfs_disable().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23146 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mfd: ene-kb3930: Fix a potential NULL pointer dereferenceThe off_gpios could be NULL. Add missing check in the kb3930_probe().This is similar to the issue fixed in commit b1ba8bcb2d1f("backlight: hx8357: Fix potential NULL pointer dereference").This was detected by our static analysis tool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23147 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i3c: Add NULL pointer check in i3c_master_queue_ibi()The I3C master driver may receive an IBI from a target device that has notbeen probed yet. In such cases, the master calls `i3c_master_queue_ibi()`to queue an IBI work task, leading to "Unable to handle kernel read fromunreadable memory" and resulting in a kernel panic.Typical IBI handling flow:1. The I3C master scans target devices and probes their respective drivers.2. The target device driver calls `i3c_device_request_ibi()` to enable IBI and assigns `dev->ibi = ibi`.3. The I3C master receives an IBI from the target device and calls `i3c_master_queue_ibi()` to queue the target device driver's IBI handler task.However, since target device events are asynchronous to the I3C probesequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`,leading to a kernel panic.Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessingan uninitialized `dev->ibi`, ensuring stability.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23148 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()soc_dev_attr->revision could be NULL, thus,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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23150 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix off-by-one error in do_splitSyzkaller detected a use-after-free issue in ext4_insert_dentry that wascaused by out-of-bounds access due to incorrect splitting in do_split.BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/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:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 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 The following loop is located right above 'if' statement.for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++;}'i' in this case could go down to -1, in which case sum of active entrieswouldn't exceed half the block size, but previous behaviour would also dosplit in half if sum would exceed at the very last block, which in case ofhaving too many long name files in a single block could lead toout-of-bounds access and following use-after-free.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23156 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi_parser: refactor hfi packet parsing logicwords_count denotes the number of words in total payload, while datapoints to payload of various property within it. When words_countreaches last word, data can access memory beyond the total payload. Thiscan lead to OOB access. With this patch, the utility api for handlingindividual properties now returns the size of data consumed. Accordinglyremaining bytes are calculated before parsing the payload, therebyeliminates the OOB access possibilities.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23157 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi_parser: add check to avoid out of bound accessThere is a possibility that init_codecs is invoked multiple times duringmanipulated payload from video firmware. In such case, if codecs_countcan get incremented to value more than MAX_CODEC_NUM, there can be OOBaccess. Reset the count so that it always starts from beginning.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23158 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi: add check to handle incorrect queue sizeqsize represents size of shared queued between driver and videofirmware. Firmware can modify this value to an invalid large value. Insuch situation, empty_space will be bigger than the space actuallyavailable. Since new_wr_idx is not checked, so the following code willresult in an OOB write....qsize = qhdr->q_sizeif (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx)....if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB writeAdd check to ensure qsize is within the allocated size whilereading and writing packets into the queue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23159 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi: add a check to handle OOB in sfr regionsfr->buf_size is in shared memory and can be modified by malicious user.OOB write is possible when the size is made higher than actual sfr databuffer. Cap the size to allocated size for such cases.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23161 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t typeThe access to the PCI config space via pci_ops::read and pci_ops::write isa low-level hardware access. The functions can be accessed with disabledinterrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for thispurpose.A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot beacquired with disabled interrupts. The vmd_dev::cfg_lock is accessed inthe same context as the pci_lock.Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used withinterrupts disabled.This was reported as: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90[bigeasy: reword commit message]Tested-off-by: Luis Claudio R. Goncalves [kwilczynski: commit log][bhelgaas: add back report info fromhttps://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-23163 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: vlan: don't propagate flags on openWith the device instance lock, there is now a possibility of a deadlock:[ 1.211455] ============================================[ 1.211571] WARNING: possible recursive locking detected[ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted[ 1.211823] --------------------------------------------[ 1.211936] ip/184 is trying to acquire lock:[ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0[ 1.212207][ 1.212207] but task is already holding lock:[ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0[ 1.212487][ 1.212487] other info that might help us debug this:[ 1.212626] Possible unsafe locking scenario:[ 1.212626][ 1.212751] CPU0[ 1.212815] ----[ 1.212871] lock(&dev->lock);[ 1.212944] lock(&dev->lock);[ 1.213016][ 1.213016] *** DEADLOCK ***[ 1.213016][ 1.213143] May be due to missing lock nesting notation[ 1.213143][ 1.213294] 3 locks held by ip/184:[ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0[ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0[ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0[ 1.213895][ 1.213895] stack backtrace:[ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5[ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014[ 1.213994] Call Trace:[ 1.213995] [ 1.213996] dump_stack_lvl+0x8e/0xd0[ 1.214000] print_deadlock_bug+0x28b/0x2a0[ 1.214020] lock_acquire+0xea/0x2a0[ 1.214027] __mutex_lock+0xbf/0xd40[ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI[ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev[ 1.214042] __dev_open+0x145/0x270[ 1.214046] __dev_change_flags+0xb0/0x1e0[ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev[ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info[ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0[ 1.214058] notifier_call_chain+0x78/0x120[ 1.214062] netif_open+0x6d/0x90[ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0[ 1.214066] bond_enslave+0x64c/0x1230[ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0[ 1.214077] do_setlink+0x516/0x13b0[ 1.214094] rtnl_newlink+0xaba/0xb80[ 1.214132] rtnetlink_rcv_msg+0x440/0x490[ 1.214144] netlink_rcv_skb+0xeb/0x120[ 1.214150] netlink_unicast+0x1f9/0x320[ 1.214153] netlink_sendmsg+0x346/0x3f0[ 1.214157] __sock_sendmsg+0x86/0xb0[ 1.214160] ____sys_sendmsg+0x1c8/0x220[ 1.214164] ___sys_sendmsg+0x28f/0x2d0[ 1.214179] __x64_sys_sendmsg+0xef/0x140[ 1.214184] do_syscall_64+0xec/0x1d0[ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 1.214191] RIP: 0033:0x7f2d1b4a7e56Device setup: netdevsim0 (down) ^ ^ bond netdevsim1.100@netdevsim1 allmulticast=on (down)When we enslave the lower device (netdevsim0) which has a vlan, wepropagate vlan's allmuti/promisc flags during ndo_open. This causes(re)locking on of the real_dev.Propagate allmulti/promisc on flags change, not on the open. Thereis a slight semantics change that vlans that are down now propagatethe flags, but this seems unlikely to result in the real issues.Reproducer: echo 0 1 > /sys/bus/netdevsim/new_device dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*) dev=$(echo $dev_path | rev | cut -d/ -f1 | rev) ip link set dev $dev name netdevsim0 ip link set dev netdevsim0 up ip link add link netdevsim0 name netdevsim0.100 type vlan id 100 ip link set dev netdevsim0.100 allm---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37750 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix UAF in decryption with multichannelAfter commit f7025d861694 ("smb: client: allocate crypto only forprimary server") and commit b0abcd65ec54 ("smb: client: fix UAF inasync decryption"), the channels started reusing AEAD TFM from primarychannel to perform synchronous decryption, but that can't done asthere could be multiple cifsd threads (one per channel) simultaneouslyaccessing it to perform decryption.This fixes the following KASAN splat when running fstest generic/249with 'vers=3.1.1,multichannel,max_channels=4,seal' against WindowsServer 2022:BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xba/0x110Read of size 8 at addr ffff8881046c18a0 by task cifsd/986CPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc4104/01/2014Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x156/0x528 ? gf128mul_4k_lle+0xba/0x110 ? __virt_addr_valid+0x145/0x300 ? __phys_addr+0x46/0x90 ? gf128mul_4k_lle+0xba/0x110 kasan_report+0xdf/0x1a0 ? gf128mul_4k_lle+0xba/0x110 gf128mul_4k_lle+0xba/0x110 ghash_update+0x189/0x210 shash_ahash_update+0x295/0x370 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_extract_iter_to_sg+0x10/0x10 ? ___kmalloc_large_node+0x10e/0x180 ? __asan_memset+0x23/0x50 crypto_ahash_update+0x3c/0xc0 gcm_hash_assoc_remain_continue+0x93/0xc0 crypt_message+0xe09/0xec0 [cifs] ? __pfx_crypt_message+0x10/0x10 [cifs] ? _raw_spin_unlock+0x23/0x40 ? __pfx_cifs_readv_from_socket+0x10/0x10 [cifs] decrypt_raw_data+0x229/0x380 [cifs] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] ? __pfx_cifs_read_iter_from_socket+0x10/0x10 [cifs] smb3_receive_transform+0x837/0xc80 [cifs] ? __pfx_smb3_receive_transform+0x10/0x10 [cifs] ? __pfx___might_resched+0x10/0x10 ? __pfx_smb3_is_transform_hdr+0x10/0x10 [cifs] cifs_demultiplex_thread+0x692/0x1570 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? rcu_lockdep_current_cpu_online+0x62/0xb0 ? find_held_lock+0x32/0x90 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xd/0xd0 ? trace_irq_enable.constprop.0+0xa8/0xe0 ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0x1fe/0x380 ? kthread+0x10f/0x380 ? __pfx_kthread+0x10/0x10 ? local_clock_noinstr+0xd/0xd0 ? ret_from_fork+0x1b/0x60 ? local_clock+0x15/0x30 ? lock_release+0x29b/0x390 ? rcu_is_watching+0x20/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37756 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: tls: explicitly disallow disconnectsyzbot discovered that it can disconnect a TLS socket and thenrun into all sort of unexpected corner cases. I have a vaguerecollection of Eric pointing this out to us a long time ago.Supporting disconnect is really hard, for one thing if offloadis enabled we'd need to wait for all packets to be _acked_.Disconnect is not commonly used, disallow it.The immediate problem syzbot run into is the warning in the strp,but that's just the easiest bug to trigger: WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37757 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix memory leak in tipc_link_xmitIn case the backlog transmit queue for system-importance messages is overloaded,tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads tomemory leak and failure when a skb is allocated.This commit fixes this issue by purging the skb list before tipc_link_xmit()returns.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37765 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: prime: fix ttm_bo_delayed_delete oopsFix an oops in ttm_bo_delayed_delete which results from dererencing adangling pointer:Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMPCPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024Workqueue: ttm ttm_bo_delayed_delete [ttm]RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8bRSP: 0018:ffffbf9383473d60 EFLAGS: 00010202RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6bR13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383ccFS: 0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0PKRU: 55555554Call Trace: ? __die_body.cold+0x19/0x26 ? die_addr+0x3d/0x70 ? exc_general_protection+0x159/0x460 ? asm_exc_general_protection+0x27/0x30 ? dma_resv_iter_first_unlocked+0x55/0x290 dma_resv_wait_timeout+0x56/0x100 ttm_bo_delayed_delete+0x69/0xb0 [ttm] process_one_work+0x217/0x5c0 worker_thread+0x1c8/0x3d0 ? apply_wqattrs_cleanup.part.0+0xc0/0xc0 kthread+0x10b/0x240 ? kthreads_online_cpu+0x140/0x140 ret_from_fork+0x40/0x70 ? kthreads_online_cpu+0x140/0x140 ret_from_fork_asm+0x11/0x20 The cause of this is:- drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the reference to the shared dma_buf. The reference count is 0, so the dma_buf is destroyed, which in turn decrements the corresponding amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed - calling drm_gem_object_release then dma_resv_fini (which destroys the reservation object), then finally freeing the amdgpu_bo.- nouveau_bo obj->bo.base.resv is now a dangling pointer to the memory formerly allocated to the amdgpu_bo.- nouveau_gem_object_del calls ttm_bo_put(&nvbo->bo) which calls ttm_bo_release, which schedules ttm_bo_delayed_delete.- ttm_bo_delayed_delete runs and dereferences the dangling resv pointer, resulting in a general protection fault.Fix this by moving the drm_prime_gem_destroy call fromnouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it willbe run after ttm_bo_delayed_delete.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37766 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37767 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37768 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37770 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37773 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virtiofs: add filesystem context source name checkIn certain scenarios, for example, during fuzz testing, the sourcename may be NULL, which could lead to a kernel panic. Therefore, anextra check for the source name should be added.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37780 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:isofs: Prevent the use of too small fidsyzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]The handle_bytes value passed in by the reproducing program is equal to 12.In handle_to_path(), only 12 bytes of memory are allocated for the structurefile_handle->f_handle member, which causes an out-of-bounds access whenaccessing the member parent_block of the structure isofs_fid in isofs,because accessing parent_block requires at least 16 bytes of f_handle.Here, fh_len is used to indirectly confirm that the value of handle_bytesis greater than 3 before accessing parent_block.[1]BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0Hardware 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 lib/dump_stack.c:94 [inline] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [inline] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __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+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Allocated by task 6466: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [inline] handle_to_path fs/fhandle.c:357 [inline] do_handle_open+0x5a4/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __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+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37781 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: cros-ec-tunnel: defer probe if parent EC is not presentWhen i2c-cros-ec-tunnel and the EC driver are built-in, the EC parentdevice will not be found, leading to NULL pointer dereference.That can also be reproduced by unbinding the controller driver and thenloading i2c-cros-ec-tunnel module (or binding the device).[ 271.991245] BUG: kernel NULL pointer dereference, address: 0000000000000058[ 271.998215] #PF: supervisor read access in kernel mode[ 272.003351] #PF: error_code(0x0000) - not-present page[ 272.008485] PGD 0 P4D 0[ 272.011022] Oops: Oops: 0000 [#1] SMP NOPTI[ 272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S 6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full) 3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5[ 272.030312] Tainted: [S]=CPU_OUT_OF_SPEC[ 272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021[ 272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel][ 272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 <49> 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9[ 272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282[ 272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000[ 272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00[ 272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000[ 272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000[ 272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10[ 272.108198] FS: 00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000[ 272.116282] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0[ 272.129155] Call Trace:[ 272.131606] [ 272.133709] ? acpi_dev_pm_attach+0xdd/0x110[ 272.137985] platform_probe+0x69/0xa0[ 272.141652] really_probe+0x152/0x310[ 272.145318] __driver_probe_device+0x77/0x110[ 272.149678] driver_probe_device+0x1e/0x190[ 272.153864] __driver_attach+0x10b/0x1e0[ 272.157790] ? driver_attach+0x20/0x20[ 272.161542] bus_for_each_dev+0x107/0x150[ 272.165553] bus_add_driver+0x15d/0x270[ 272.169392] driver_register+0x65/0x110[ 272.173232] ? cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698][ 272.182617] do_one_initcall+0x110/0x350[ 272.186543] ? security_kernfs_init_security+0x49/0xd0[ 272.191682] ? __kernfs_new_node+0x1b9/0x240[ 272.195954] ? security_kernfs_init_security+0x49/0xd0[ 272.201093] ? __kernfs_new_node+0x1b9/0x240[ 272.205365] ? kernfs_link_sibling+0x105/0x130[ 272.209810] ? kernfs_next_descendant_post+0x1c/0xa0[ 272.214773] ? kernfs_activate+0x57/0x70[ 272.218699] ? kernfs_add_one+0x118/0x160[ 272.222710] ? __kernfs_create_file+0x71/0xa0[ 272.227069] ? sysfs_add_bin_file_mode_ns+0xd6/0x110[ 272.232033] ? internal_create_group+0x453/0x4a0[ 272.236651] ? __vunmap_range_noflush+0x214/0x2d0[ 272.241355] ? __free_frozen_pages+0x1dc/0x420[ 272.245799] ? free_vmap_area_noflush+0x10a/0x1c0[ 272.250505] ? load_module+0x1509/0x16f0[ 272.254431] do_init_module+0x60/0x230[ 272.258181] __se_sys_finit_module+0x27a/0x370[ 272.262627] do_syscall_64+0x6a/0xf0[ 272.266206] ? do_syscall_64+0x76/0xf0[ 272.269956] ? irqentry_exit_to_user_mode+0x79/0x90[ 272.274836] entry_SYSCALL_64_after_hwframe+0x55/0x5d[ 272.279887] RIP: 0033:0x7b9309168d39[ 272.283466] Code: 5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 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 8b 0d af 40 0c 00 f7 d8 64 89 01 8[ 272.302210] RSP: 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37786 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: free routing table on probe failureIf complete = true in dsa_tree_setup(), it means that we are the lastswitch of the tree which is successfully probing, and we should besetting up all switches from our probe path.After "complete" becomes true, dsa_tree_setup_cpu_ports() or anysubsequent function may fail. If that happens, the entire tree setup isin limbo: the first N-1 switches have successfully finished probing(doing nothing but having allocated persistent memory in the tree'sdst->ports, and maybe dst->rtable), and switch N failed to probe, endingthe tree setup process before anything is tangible from the user's PoV.If switch N fails to probe, its memory (ports) will be freed and removedfrom dst->ports. However, the dst->rtable elements pointing to its ports,as created by dsa_link_touch(), will remain there, and will lead touse-after-free if dereferenced.If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirelypossible because that is where ds->ops->setup() is, we get a kasanreport like this:==================================================================BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350The simplest way to fix the bug is to delete the routing table in itsentirety. dsa_tree_setup_routing_table() has no problem in regeneratingit even if we deleted links between ports other than those of switch N,because dsa_link_touch() first checks whether the port pair alreadyexists in dst->rtable, allocating if not.The deletion of the routing table in its entirety already exists indsa_tree_teardown(), so refactor that into a function that can also becalled from the tree setup error path.In my analysis of the commit to blame, it is the one which addeddsa_link elements to dst->rtable. Prior to that, each switch had its ownds->rtable which is freed when the switch fails to probe. But the treeis potentially persistent memory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: avoid unregistering devlink regions which were never registeredRussell King reports that a system with mv88e6xxx dereferences a NULLpointer when unbinding this driver:https://lore.kernel.org/netdev/Z_lRkMlTJ1KQ0kVX@shell.armlinux.org.uk/The crash seems to be in devlink_region_destroy(), which is not NULLtolerant but is given a NULL devlink global region pointer.At least on some chips, some devlink regions are conditionally registeredsince the blamed commit, see mv88e6xxx_setup_devlink_regions_global(): if (cond && !cond(chip)) continue;These are MV88E6XXX_REGION_STU and MV88E6XXX_REGION_PVT. If the chipdoes not have an STU or PVT, it should crash like this.To fix the issue, avoid unregistering those regions which are NULL, i.e.were skipped at mv88e6xxx_setup_devlink_regions_global() time.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37788 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cxgb4: fix memory leak in cxgb4_init_ethtool_filters() error pathIn the for loop used to allocate the loc_array and bmap for each port, amemory leak is possible when the allocation for loc_array succeeds,but the allocation for bmap fails. This is because when the control flowgoes to the label free_eth_finfo, only the allocations starting from(i-1)th iteration are freed.Fix that by freeing the loc_array in the bmap allocation error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37792 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btrtl: Prevent potential NULL dereferenceThe btrtl_initialize() function checks that rtl_load_file() eitherhad an error or it loaded a zero length file. However, if it loadeda zero length file then the error code is not set correctly. Itresults in an error pointer vs NULL bug, followed by a NULL pointerdereference. This was detected by Smatch:drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37794 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Purge vif txq in ieee80211_do_stop()After ieee80211_do_stop() SKB from vif's txq could still be processed.Indeed another concurrent vif schedule_and_wake_txq call could causethose packets to be dequeued (see ieee80211_handle_wake_tx_queue())without checking the sdata current state.Because vif.drv_priv is now cleared in this function, this could lead todriver crash.For example in ath12k, ahvif is store in vif.drv_priv. Thus ifath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can beNULL, leading the ath12k_warn(ahvif->ah,...) call in this function totrigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158To avoid that, empty vif's txq at ieee80211_do_stop() so no packet couldbe dequeued after ieee80211_do_stop() (new packets cannot be queuedbecause SDATA_STATE_RUNNING is cleared at this point).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37796 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: at76c50x: fix use after free access in at76_disconnectThe memory pointed to by priv is freed at the end of at76_delete_devicefunction (using ieee80211_free_hw). But the code then accesses the udevfield of the freed object to put the USB device. This may also lead to amemory leak of the usb device. Fix this by using udev from interface.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37803 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udmabuf: fix a buf size overflow issue during udmabuf creationby casting size_limit_mb to u64 when calculate pglimit.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37804 Severity: Moderate CVSS3 score: 5.5

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

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37817 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mcb: fix a double free bug in chameleon_parse_gdd()In chameleon_parse_gdd(), if mcb_device_register() fails, 'mdev'would be released in mcb_device_register() via put_device().Thus, goto 'err' label and free 'mdev' again causes a double free.Just return if mcb_device_register() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37819 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode()With ACPI in place, gicv2m_get_fwnode() is registered with the pcisubsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtimeduring a PCI host bridge probe. But, the call back is wrongly marked as__init, causing it to be freed, while being registered with the PCIsubsystem and could trigger: Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548This is easily reproducible on a Juno board with ACPI boot.Retain the function for later use.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37820 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xen-netfront: handle NULL returned by xdp_convert_buff_to_frame()The function xdp_convert_buff_to_frame() may return NULL if it failsto correctly convert the XDP buffer into an XDP frame due to memoryconstraints, internal errors, or invalid data. Failing to check for NULLmay lead to a NULL pointer dereference if the result is used later inprocessing, potentially causing crashes, data corruption, or undefinedbehavior.On XDP redirect failure, the associated page must be released explicitlyif it was previously retained via get_page(). Failing to do so may resultin a memory leak, as the pages reference count is not decremented.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37824 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix NULL pointer dereference in tipc_mon_reinit_self()syzbot reported:tipc: Node number set to 1055423674Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #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: events tipc_net_finalize_workRIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719...RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cbaRDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 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 ...RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719...RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cbaRDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400There is a racing condition between workqueue created when enablingbearer and another thread created when disabling bearer right afterthat as follow:enabling_bearer | disabling_bearer--------------- | ----------------tipc_disc_timeout() |{ | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | {} | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | }tipc_net_finalize_work() | }{ | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37829 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()cpufreq_cpu_get_raw() can return NULL when the target CPU is not presentin the policy->cpus mask. scpi_cpufreq_get_rate() does not check forthis case, which results in a NULL pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37830 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate()cpufreq_cpu_get_raw() can return NULL when the target CPU is not presentin the policy->cpus mask. scmi_cpufreq_get_rate() does not check forthis case, which results in a NULL pointer dereference.Add NULL check after cpufreq_cpu_get_raw() to prevent this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37833 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry readsFix niu_try_msix() to not cause a fatal trap on sparc systems.Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev towork around a bug in the hardware or firmware.For each vector entry in the msix table, niu chips will cause a fataltrap if any registers in that entry are read before that entries'ENTRY_DATA register is written to. Testing indicates writes to otherregisters are not sufficient to prevent the fatal trap, however the valuedoes not appear to matter. This only needs to happen once after power up,so simply rebooting into a kernel lacking this fix will NOT cause thetrap.NON-RESUMABLE ERROR: Reporting on cpu 64NON-RESUMABLE ERROR: TPC [0x00000000005f6900] NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffffNON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000]NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff]NON-RESUMABLE ERROR: type [precise nonresumable]NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv >NON-RESUMABLE ERROR: raddr [0xffffffffffffffff]NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c]NON-RESUMABLE ERROR: size [0x8]NON-RESUMABLE ERROR: asi [0x00]CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63Workqueue: events work_for_cpu_fnTSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not taintedTPC: g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128RPC: <__pci_enable_msix_range+0x3cc/0x460>l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000di4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0I7: Call Trace:[<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu][<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu][<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu][<00000000005ef3e4>] local_pci_probe+0x28/0x74[<0000000000469240>] work_for_cpu_fn+0x8/0x1c[<000000000046b008>] process_scheduled_works+0x144/0x210[<000000000046b518>] worker_thread+0x13c/0x1c0[<00000000004710e0>] kthread+0xb8/0xc8[<00000000004060c8>] ret_from_fork+0x1c/0x2c[<0000000000000000>] 0x0Kernel panic - not syncing: Non-resumable error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37836 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Fix reference leak in pci_register_host_bridge()If device_register() fails, call put_device() to give up the reference toavoid a memory leak, per the comment at device_register().Found by code review.[bhelgaas: squash Dan Carpenter's double free fix fromhttps://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37840 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: brcmnand: fix PM resume warningFixed warning on PM resume as shown below caused due to uninitializedstruct nand_operation that checks chip select field :WARN_ON(op->cs >= nanddev_ntargets(&chip->base)[ 14.588522] ------------[ cut here ]------------[ 14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8[ 14.588553] Modules linked in: bdc udc_core[ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G W 6.14.0-rc4-g5394eea10651 #16[ 14.588590] Tainted: [W]=WARN[ 14.588593] Hardware name: Broadcom STB (Flattened Device Tree)[ 14.588598] Call trace:[ 14.588604] dump_backtrace from show_stack+0x18/0x1c[ 14.588622] r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c[ 14.588625] show_stack from dump_stack_lvl+0x70/0x7c[ 14.588639] dump_stack_lvl from dump_stack+0x18/0x1c[ 14.588653] r5:c08d40b0 r4:c1003cb0[ 14.588656] dump_stack from __warn+0x84/0xe4[ 14.588668] __warn from warn_slowpath_fmt+0x18c/0x194[ 14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000[ 14.588681] warn_slowpath_fmt from nand_reset_op+0x1e0/0x1f8[ 14.588695] r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048[ 14.588697] nand_reset_op from brcmnand_resume+0x13c/0x150[ 14.588714] r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040[ 14.588717] brcmnand_resume from platform_pm_resume+0x34/0x54[ 14.588735] r5:00000010 r4:c0840a50[ 14.588738] platform_pm_resume from dpm_run_callback+0x5c/0x14c[ 14.588757] dpm_run_callback from device_resume+0xc0/0x324[ 14.588776] r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010[ 14.588779] device_resume from dpm_resume+0x130/0x160[ 14.588799] r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0[ 14.588802] dpm_resume from dpm_resume_end+0x14/0x20[ 14.588822] r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414[ 14.588826] r4:00000010[ 14.588828] dpm_resume_end from suspend_devices_and_enter+0x274/0x6f8[ 14.588848] r5:c228a414 r4:00000000[ 14.588851] suspend_devices_and_enter from pm_suspend+0x228/0x2bc[ 14.588868] r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000[ 14.588871] r4:00000003[ 14.588874] pm_suspend from state_store+0x74/0xd0[ 14.588889] r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003[ 14.588892] state_store from kobj_attr_store+0x1c/0x28[ 14.588913] r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250[ 14.588916] kobj_attr_store from sysfs_kf_write+0x40/0x4c[ 14.588936] r5:c3502900 r4:c0d92a48[ 14.588939] sysfs_kf_write from kernfs_fop_write_iter+0x104/0x1f0[ 14.588956] r5:c3502900 r4:c3501f40[ 14.588960] kernfs_fop_write_iter from vfs_write+0x250/0x420[ 14.588980] r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00[ 14.588983] r4:c042a88c[ 14.588987] vfs_write from ksys_write+0x74/0xe4[ 14.589005] r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00[ 14.589008] r4:c34f7f00[ 14.589011] ksys_write from sys_write+0x10/0x14[ 14.589029] r7:00000004 r6:004421c0 r5:00443398 r4:00000004[ 14.589032] sys_write from ret_fast_syscall+0x0/0x5c[ 14.589044] Exception stack(0xf09f9fa8 to 0xf09f9ff0)[ 14.589050] 9fa0: 00000004 00443398 00000004 00443398 00000004 00000001[ 14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78[ 14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8[ 14.589065] ---[ end trace 0000000000000000 ]---The fix uses the higher level nand_reset(chip, chipnr); where chipnr = 0, whendoing PM resume operation in compliance with the controller support for singledie nand chip. Switching from nand_reset_op() to nan---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37842 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: fsl-qspi: use devm function instead of driver removeDriver use devm APIs to manage clk/irq/resources and register the spicontroller, but the legacy remove function will be called first duringdevice detach and trigger kernel panic. Drop the remove function and usedevm_add_action_or_reset() for driver cleanup to ensure the releasesequence.Trigger kernel panic on i.MX8MQ byecho 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37844 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: avoid NULL pointer dereference in dbg callcifs_server_dbg() implies server to be non-NULL somove call under condition to avoid NULL pointer dereference.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create()Add error handling to propagate amdgpu_cgs_create_device() failuresto the caller. When amdgpu_cgs_create_device() fails, release hwmgrand return -ENOMEM to prevent null pointer dereference.[v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: debugfs hang_hws skip GPU with MESdebugfs hang_hws is used by GPU reset test with HWS, for MES this crashthe kernel with NULL pointer access because dqm->packet_mgr is not setupfor MES path.Skip GPU with MES for now, MES hang_hws debugfs interface will besupported later.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37862 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: pidff: Fix null pointer dereference in pidff_find_fieldsThis function triggered a null pointer dereference if used to search fora report that isn't implemented on the device. This happened both foroptional and required reports alike.The same logic was applied to pidff_find_special_field and althoughpidff_init_fields should return an error earlier if one of the requiredreports is missing, future modifications could change this logic andresurface this possible null pointer dereference again.LKML bug report:https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37867 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Silence oversized kvmalloc() warningsyzkaller triggered an oversized kvmalloc() warning.Silence it by adding __GFP_NOWARN.syzkaller log: WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180 CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__kvmalloc_node_noprof+0x175/0x180 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246 RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002 RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000 R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000 FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ib_umem_odp_get+0x1f6/0x390 mlx5_ib_reg_user_mr+0x1e8/0x450 ib_uverbs_reg_mr+0x28b/0x440 ib_uverbs_write+0x7d3/0xa30 vfs_write+0x1ac/0x6c0 ksys_write+0x134/0x170 ? __sanitizer_cov_trace_pc+0x1c/0x50 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37875 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:igc: fix PTM cycle trigger logicWriting to clear the PTM status 'valid' bit while the PTM cycle istriggered results in unreliable PTM operation. To fix this, clear thePTM 'trigger' and status after each PTM transaction.The issue can be reproduced with the following:$ sudo phc2sys -R 1000 -O 0 -i tsn0 -mNote: 1000 Hz (-R 1000) is unrealistically large, but provides a way toquickly reproduce the issue.PHC2SYS exits with:"ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction failsThis patch also fixes a hang in igc_probe() when loading the igcdriver in the kdump kernel on systems supporting PTM.The igc driver running in the base kernel enables PTM trigger inigc_probe(). Therefore the driver is always in PTM trigger mode,except in brief periods when manually triggering a PTM cycle.When a crash occurs, the NIC is reset while PTM trigger is enabled.Due to a hardware problem, the NIC is subsequently in a bad busmasterstate and doesn't handle register reads/writes. When runningigc_probe() in the kdump kernel, the first register access to a NICregister hangs driver probing and ultimately breaks kdump.With this patch, igc has PTM trigger disabled most of the time,and the trigger is only enabled for very brief (10 - 100 us) periodswhen manually triggering a PTM cycle. Chances that a crash occursduring a PTM trigger are not 0, but extremely reduced.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37879 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:9p/net: fix improper handling of bogus negative read/write repliesIn p9_client_write() and p9_client_read_once(), if the serverincorrectly replies with success but a negative write/read count then wewould consider written (negative) <= rsize (positive) because bothvariables were signed.Make variables unsigned to avoid this problem.The reproducer linked below now fails with the following error insteadof a null pointer deref:9pnet: bogus RWRITE count (4294967295 > 3)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev()The variable d->name, returned by 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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37913 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: qfq: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of qfq, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.This patch checks whether the class was already added to the agg->activelist (cl_is_active) before doing the addition to cater for the reentrantcase.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37914 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: ets: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of ets, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.In addition to checking for qlen being zero, this patch checks whetherthe class was already added to the active_list (cl_is_active) beforedoing the addition to cater for the reentrant case.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37915 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: drr: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of drr, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.In addition to checking for qlen being zero, this patch checks whether theclass was already added to the active_list (cl_is_active) before addingto the list to cover for the reentrant case.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: adjust subpage bit start based on sectorsizeWhen running machines with 64k page size and a 16k nodesize we startedseeing tree log corruption in production. This turned out to be becausewe were not writing out dirty blocks sometimes, so this in fact affectsall metadata writes.When writing out a subpage EB we scan the subpage bitmap for a dirtyrange. If the range isn't dirty we do bit_start++;to move onto the next bit. The problem is the bitmap is based on thenumber of sectors that an EB has. So in this case, we have a 64kpagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4bits for every node. With a 64k page size we end up with 4 nodes perpage.To make this easier this is how everything looks[0 16k 32k 48k ] logical address[0 4 8 12 ] radix tree offset[ 64k page ] folio[ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers[ | | | | | | | | | | | | | | | | ] bitmapNow we use all of our addressing based on fs_info->sectorsize_bits, soas you can see the above our 16k eb->start turns into radix entry 4.When we find a dirty range for our eb, we correctly do bit_start +=sectors_per_node, because if we start at bit 0, the next bit for thenext eb is 4, to correspond to eb->start 16k.However if our range is clean, we will do bit_start++, which will nowput us offset from our radix tree entries.In our case, assume that the first time we check the bitmap the block isnot dirty, we increment bit_start so now it == 1, and then we looparound and check again. This time it is dirty, and we go to find thatstart using the following equation start = folio_start + bit_start * fs_info->sectorsize;so in the case above, eb->start 0 is now dirty, and we calculate startas 0 + 1 * fs_info->sectorsize = 4096 4096 >> 12 = 1Now we're looking up the radix tree for 1, and we won't find an eb.What's worse is now we're using bit_start == 1, so we do bit_start +=sectors_per_node, which is now 5. If that eb is dirty we will run intothe same thing, we will look at an offset that is not populated in theradix tree, and now we're skipping the writeout of dirty extent buffers.The best fix for this is to not use sectorsize_bits to address nodes,but that's a larger change. Since this is a fs corruption problem fixit simply by always using sectors_per_node to increment the start bit.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37937 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()If dib8000_set_dds()'s call to dib8000_read32() returns zero, the resultis a divide-by-zero. Prevent that from happening.Fixes the following warning with an UBSAN kernel: drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37938 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Verify event formats that have "%*p.."The trace event verifier checks the formats of trace events to make surethat they do not point at memory that is not in the trace event itself orin data that will never be freed. If an event references data that wasallocated when the event triggered and that same data is freed before theevent is read, then the kernel can crash by reading freed memory.The verifier runs at boot up (or module load) and scans the print formatsof the events and checks their arguments to make sure that dereferencedpointers are safe. If the format uses "%*p.." the verifier will ignore it,and that could be dangerous. Cover this case as well.Also add to the sample code a use case of "%*pbl".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37940 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Add cond_resched() to ftrace_graph_set_hash()When the kernel contains a large number of functions that can be traced,the loop in ftrace_graph_set_hash() may take a lot of time to execute.This may trigger the softlockup watchdog.Add cond_resched() within the loop to allow the kernel to remainresponsive even when processing a large number of functions.This matches the cond_resched() that is used in other locations of thecode that iterates over all functions that can be traced.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37945 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHYDSA has 2 kinds of drivers:1. Those who call dsa_switch_suspend() and dsa_switch_resume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz2. Those who don't: all others. The above methods should be optional.For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(),and dsa_switch_resume() calls dsa_user_resume() -> phylink_start().These seem good candidates for setting mac_managed_pm = true becausethat is essentially its definition [1], but that does not seem to be thebiggest problem for now, and is not what this change focuses on.Talking strictly about the 2nd category of DSA drivers here (whichdo not have MAC managed PM, meaning that for their attached PHYs,mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),I have noticed that the following warning from mdio_bus_phy_resume() istriggered: WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY && phydev->state != PHY_UP);because the PHY state machine is running.It's running as a result of a previous dsa_user_open() -> ... ->phylink_start() -> phy_start() having been initiated by the user.The previous mdio_bus_phy_suspend() was supposed to have calledphy_stop_machine(), but it didn't. So this is why the PHY is in statePHY_NOLINK by the time mdio_bus_phy_resume() runs.mdio_bus_phy_suspend() did not call phy_stop_machine() because forphylink, the phydev->adjust_link function pointer is NULL. This seems atechnicality introduced by commit fddd91016d16 ("phylib: fix PAL statemachine restart on resume"). That commit was written before phylinkexisted, and was intended to avoid crashing with consumer drivers whichdon't use the PHY state machine - phylink always does, when using a PHY.But phylink itself has historically not been developed withsuspend/resume in mind, and apparently not tested too much in thatscenario, allowing this bug to exist unnoticed for so long. Plus, priorto the WARN_ON(), it would have likely been invisible.This issue is not in fact restricted to type 2 DSA drivers (according tothe above ad-hoc classification), but can be extrapolated to any MACdriver with phylink and MDIO-bus-managed PHY PM ops. DSA is just wherethe issue was reported. Assuming mac_managed_pm is set correctly, aquick search indicates the following other drivers might be affected:$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pmdrivers/net/ethernet/atheros/ag71xx.cdrivers/net/ethernet/microchip/sparx5/sparx5_main.cdrivers/net/ethernet/microchip/lan966x/lan966x_main.cdrivers/net/ethernet/freescale/dpaa2/dpaa2-mac.cdrivers/net/ethernet/freescale/fs_enet/fs_enet-main.cdrivers/net/ethernet/freescale/dpaa/dpaa_eth.cdrivers/net/ethernet/freescale/ucc_geth.cdrivers/net/ethernet/freescale/enetc/enetc_pf_common.cdrivers/net/ethernet/marvell/mvpp2/mvpp2_main.cdrivers/net/ethernet/marvell/mvneta.cdrivers/net/ethernet/marvell/prestera/prestera_main.cdrivers/net/ethernet/mediatek/mtk_eth_soc.cdrivers/net/ethernet/altera/altera_tse_main.cdrivers/net/ethernet/wangxun/txgbe/txgbe_phy.cdrivers/net/ethernet/meta/fbnic/fbnic_phylink.cdrivers/net/ethernet/tehuti/tn40_phy.cdrivers/net/ethernet/mscc/ocelot_net.cMake the existing conditions dependent on the PHY device having aphydev->phy_link_change() implementation equal to the defaultphy_link_change() provided by phylib. Otherwise, we implicitly know thatthe phydev has the phylink-provided phylink_phy_change() callback, andwhen phylink is used, the PHY state machine always needs to be stopped/started on the suspend/resume path. The code is structured as such thatif phydev->phy_link_change() is absent, it is a matter of time until thekernel will crash - no need to further complicate the test.Thus, for the situation where the PM is not managed b---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37949 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xenbus: Use kref to track req lifetimeMarek reported seeing a NULL pointer fault in the xenbus_threadcallstack:BUG: kernel NULL pointer dereference, address: 0000000000000000RIP: e030:__wake_up_common+0x4c/0x180Call Trace: __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), athin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seemslike it was xs_wake_up() in this case.It seems like req may have woken up the xs_wait_for_reply(), whichkfree()ed the req. When xenbus_thread resumes, it faults on the zero-eddata.Linux Device Drivers 2nd edition states:"Normally, a wake_up call can cause an immediate reschedule to happen,meaning that other processes might run before wake_up returns."... which would match the behaviour observed.Change to keeping two krefs on each request. One for the caller, andone for xenbus_thread. Each will kref_put() when finished, and the lastwill free it.This use of kref matches the description inDocumentation/core-api/kref.rst

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37957 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interceptionPreviously, commit ed129ec9057f ("KVM: x86: forcibly leave nested modeon vCPU reset") addressed an issue where a triple fault occurring innested mode could lead to use-after-free scenarios. However, the commitdid not handle the analogous situation for System Management Mode (SMM).This omission results in triggering a WARN when KVM forces a vCPU INITafter SHUTDOWN interception while the vCPU is in SMM. This situation wasreprodused using Syzkaller by: 1) Creating a KVM VM and vCPU 2) Sending a KVM_SMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple faultThe issue manifests as follows: WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline] vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856 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/0xd8Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN()in kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improperemulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs todo _something_ sane with the VMCB, since it's technically undefined, andINIT is the least awful choice given KVM's ABI.So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out ofSMM to avoid any weirdness (and the WARN).Found by Linux Verification Center (linuxtesting.org) with Syzkaller.[sean: massage changelog, make it clear this isn't architectural behavior]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37959 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Scrub packet on bpf_redirect_peerWhen bpf_redirect_peer is used to redirect packets to a device inanother network namespace, the skb isn't scrubbed. That can lead skbinformation from one namespace to be "misused" in another namespace.As one example, this is causing Cilium to drop traffic when usingbpf_redirect_peer to redirect packets that just went through IPsecdecryption to a container namespace. The following pwru trace shows (1)the packet path from the host's XFRM layer to the container's XFRMlayer where it's dropped and (2) the number of active skb extensions ateach function. NETNS MARK IFACE TUPLE FUNC 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive .active_extensions = (__u8)2, [...] 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core .active_extensions = (__u8)2, [...] 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY) .active_extensions = (__u8)2,In this case, there are no XFRM policies in the container's networknamespace so the drop is unexpected. When we decrypt the IPsec packet,the XFRM state used for decryption is set in the skb extensions. Thisinformation is preserved across the netns switch. When we reach theXFRM policy check in the container's netns, __xfrm_policy_check dropsthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRMpolicy can't be found that matches the (host-side) XFRM state used fordecryption.This patch fixes this by scrubbing the packet when usingbpf_redirect_peer, as is done on typical netns switches via vethdevices except skb->mark and skb->tstamp are not zeroed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37961 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix uninit-value for saddr in do_output_route4syzbot reports for uninit-value for the saddr argument [1].commit 4754957f04f5 ("ipvs: do not use random local source address fortunnels") already implies that the input value of saddrshould be ignored but the code is still reading it which can preventto connect the route. Fix it by changing the argument to ret_saddr.[1]BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8eUninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8eCPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)Hardware name: Google Google Compute Engi---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37967 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: displayport: Fix deadlockThis patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlockfunctions to the UCSI driver. ucsi_con_mutex_lock ensures the connectormutex is only locked if a connection is established and the partner pointeris valid. This resolves a deadlock scenario whereucsi_displayport_remove_partner holds con->mutex waiting fordp_altmode_work to complete while dp_altmode_work attempts to acquire it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37968 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: opt3001: fix deadlock due to concurrent flag accessThe threaded IRQ function in this driver is reading the flag twice: once tolock a mutex and once to unlock it. Even though the code setting the flagis designed to prevent it, there are subtle cases where the flag could betrue at the mutex_lock stage and false at the mutex_unlock stage. Thisresults in the mutex not being unlocked, resulting in a deadlock.Fix it by making the opt3001_irq() code generally more robust, reading theflag into a variable and using the variable value at both stages.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37969 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifoPrevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop incase pattern_len is equal to zero and the device FIFO is not empty.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37970 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifoPrevent st_lsm6dsx_read_fifo from falling in an infinite loop in casepattern_len is equal to zero and the device FIFO is not empty.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37980 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: fix resource leak in blk_register_queue() error pathWhen registering a queue fails after blk_mq_sysfs_register() issuccessful but the function later encounters an error, we needto clean up the blk_mq_sysfs resources.Add the missing blk_mq_sysfs_unregister() call in the error pathto properly clean up these resources and prevent a memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wl1251: fix memory leak in wl1251_tx_workThe skb dequeued from tx_queue is lost when wl1251_ps_elp_wakeup failswith a -ETIMEDOUT error. Fix that by queueing the skb back to tx_queue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37985 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: wdm: close race between wdm_open and wdm_wwan_port_stopClearing WDM_WWAN_IN_USE must be the last action orwe can open a chardev whose URBs are still poisoned

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37989 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: leds: fix memory leakA network restart test on a router led to an out-of-memory condition,which was traced to a memory leak in the PHY LED trigger code.The root cause is misuse of the devm API. The registration function(phy_led_triggers_register) is called from phy_attach_direct, notphy_probe, and the unregister function (phy_led_triggers_unregister)is called from phy_detach, not phy_remove. This means the register andunregister functions can be called multiple times for the same PHYdevice, but devm-allocated memory is not freed until the driver isunbound.This also prevents kmemleak from detecting the leak, as the devm APIinternally stores the allocated pointer.Fix this by replacing devm_kzalloc/devm_kcalloc with standardkzalloc/kcalloc, and add the corresponding kfree calls in the unregisterpath.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37990 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()The function brcmf_usb_dl_writeimage() calls the functionbrcmf_usb_dl_cmd() but dose not check its return value. The'state.state' and the 'state.bytes' are uninitialized if thefunction brcmf_usb_dl_cmd() fails. It is dangerous to useuninitialized variables in the conditions.Add error handling for brcmf_usb_dl_cmd() to jump to errorhandling path if the brcmf_usb_dl_cmd() fails and the'state.state' and the 'state.bytes' are uninitialized.Improve the error message to report more detailed errorinformation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37992 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: Flush gso_skb list too during ->change()Previously, when reducing a qdisc's limit via the ->change() operation, onlythe main skb queue was trimmed, potentially leaving packets in the gso_skblist. This could result in NULL pointer dereference when we only checksch->limit against sch->q.qlen.This patch introduces a new helper, qdisc_dequeue_internal(), which ensuresboth the gso_skb list and the main queue are properly flushed when trimmingexcess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)are updated to use this helper in their ->change() routines.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-37995 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:module: ensure that kobject_put() is safe for module type kobjectsIn 'lookup_or_create_module_kobject()', an internal kobject is createdusing 'module_ktype'. So call to 'kobject_put()' on error handlingpath causes an attempt to use an uninitialized completion pointer in'module_kobject_release()'. In this scenario, we just want to releasekobject without an extra synchronization required for a regular moduleunloading process, so adding an extra check whether 'complete()' isactually required makes 'kobject_put()' safe.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38023 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfs: handle failure of nfs_get_lock_context in unlock pathWhen memory is insufficient, the allocation of nfs_lock_context innfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treatan nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)as valid and proceed to execute rpc_run_task(), this will trigger a NULLpointer dereference in nfs4_locku_prepare. For example:BUG: kernel NULL pointer dereference, address: 000000000000000cPGD 0 P4D 0Oops: Oops: 0000 [#1] SMP PTICPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40Workqueue: rpciod rpc_async_scheduleRIP: 0010:nfs4_locku_prepare+0x35/0xc2Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0Call Trace: __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in:CR2: 000000000000000c---[ end trace 0000000000000000 ]---Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails andreturn NULL to terminate subsequent rpc_run_task, preventing NULL pointerdereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38024 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bugCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fIn the function rxe_create_cq, when rxe_cq_from_init fails, the functionrxe_cleanup will be called to handle the allocated resources. In fact,some memory resources have already been freed in the functionrxe_cq_from_init. Thus, this problem will occur.The solution is to let rxe_cleanup do all the work.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38051 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix use-after-free in cifs_fill_direntThere is a race condition in the readdir concurrency process, which mayaccess the rsp buffer after it has been released, triggering thefollowing KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================POC is available in the link [1].The problem triggering process is as follows:Process 1 Process 2--------------------------------------truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38053 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix null-ptr-deref in idpf_features_checkidpf_features_check is used to validate the TX packet. skb headerlength is compared with the hardware supported value received fromthe device control plane. The value is stored in the adapter structureand to access it, vport pointer is used. During reset all the vportsare released and the vport pointer that the netdev private structurepoints to is NULL.To avoid null-ptr-deref, store the max header length value in netdevprivate structure. This also helps to cache the value and avoidaccessing adapter pointer in hot path.BUG: kernel NULL pointer dereference, address: 0000000000000068...RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf]Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x154/0x520 ? exc_page_fault+0x76/0x190 ? asm_exc_page_fault+0x26/0x30 ? idpf_features_check+0x6d/0xe0 [idpf] netif_skb_features+0x88/0x310 validate_xmit_skb+0x2a/0x2b0 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x19d/0x3a0 __dev_queue_xmit+0xb74/0xe70 ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38057 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:espintcp: fix skb leaksA few error paths are missing a kfree_skb.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38072 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:libnvdimm/labels: Fix divide error in nd_label_data_init()If a faulty CXL memory device returns a broken zero LSA size in itsmemory device information (Identify Memory Device (Opcode 4000h), CXLspec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimmdriver: Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]Code and flow:1) CXL Command 4000h returns LSA size = 02) config_size is assigned to zero LSA size (CXL pmem driver):drivers/cxl/pmem.c: .config_size = mds->lsa_size,3) max_xfer is set to zero (nvdimm driver):drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size);4) A subsequent DIV_ROUND_UP() causes a division by zero:drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,drivers/nvdimm/label.c- config_size);Fix this by checking the config size parameter by extending anexisting check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38077 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-wmi-sysman: Avoid buffer overflow in current_password_store()If the 'buf' array received from the user contains an empty string, the'length' variable will be zero. Accessing the 'buf' array element withindex 'length - 1' will result in a buffer overflow.Add a check for an empty string.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38078 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Fix race of buffer access at PCM OSS layerThe PCM OSS layer tries to clear the buffer with the silence data atinitialization (or reconfiguration) of a stream with the explicit callof snd_pcm_format_set_silence() with runtime->dma_area. But this maylead to a UAF because the accessed runtime->dma_area might be freedconcurrently, as it's performed outside the PCM ops.For avoiding it, move the code into the PCM core and perform it insidethe buffer access lock, so that it won't be changed during theoperation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38094 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: cadence: macb: Fix a possible deadlock in macb_halt_tx.There is a situation where after THALT is set high, TGO stays high aswell. Because jiffies are never updated, as we are in a context withinterrupts disabled, we never exit that loop and have a deadlock.That deadlock was noticed on a sama5d4 device that stayed locked for days.Use retries instead of jiffies so that the timeout really works and we donot have a deadlock anymore.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38115 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: fix a potential crash on gso_skb handlingSFQ has an assumption of always being able to queue at least one packet.However, after the blamed commit, sch->q.len can be inflated by packetsin sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followedby an immediate drop.Fix sfq_drop() to properly clear q->tail in this situation.ip netns add lbip link add dev to-lb type veth peer name in-lb netns lbethtool -K to-lb tso off # force qdisc to requeue gso_skbip netns exec lb ethtool -K in-lb gro on # enable NAPIip link set dev to-lb upip -netns lb link set dev in-lb upip addr add dev to-lb 192.168.20.1/24ip -netns lb addr add dev in-lb 192.168.20.2/24tc qdisc replace dev to-lb root sfq limit 100ip netns exec lb netservernetperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38147 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:calipso: Don't call calipso functions for AF_INET sk.syzkaller reported a null-ptr-deref in txopt_get(). [0]The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo,so struct ipv6_pinfo was NULL there.However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6is always set in inet6_create(), meaning the socket was not IPv6 one.The root cause is missing validation in netlbl_conn_setattr().netlbl_conn_setattr() switches branches based on structsockaddr.sa_family, which is passed from userspace. However,netlbl_conn_setattr() does not check if the address family matchesthe socket.The syzkaller must have called connect() for an IPv6 address onan IPv4 socket.We have a proper validation in tcp_v[46]_connect(), butsecurity_socket_connect() is called in the earlier stage.Let's copy the validation to netlbl_conn_setattr().[0]:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:txopt_get include/net/ipv6.h:390 [inline]RIP: 0010:Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00cRDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9eR10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0PKRU: 80000000Call Trace: calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557 netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177 selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569 selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline] selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615 selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931 security_socket_connect+0x50/0xa0 security/security.c:4598 __sys_connect_file+0xa4/0x190 net/socket.c:2067 __sys_connect+0x12c/0x170 net/socket.c:2088 __do_sys_connect net/socket.c:2098 [inline] __se_sys_connect net/socket.c:2095 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:2095 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f901b61a12dCode: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12dRDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000 Modules linked in:

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38280 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Avoid __bpf_prog_ret0_warn when jit failssyzkaller reported an issue:WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357Modules linked in:CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357Call Trace: bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105 ...When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable.This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not setand bpf_jit_enable is set to 1, causing the arch to attempt JIT the prog,but jit failed due to FAULT_INJECTION. As a result, incorrectlytreats the program as valid, when the program runs it calls`__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38285 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix WARN() in get_bpf_raw_tp_regssyzkaller reported an issue:WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861Modules linked in:CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #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:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4cRDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47Tracepoint like trace_mmap_lock_acquire_returned may cause nested callas the corner case show above, which will be resolved with more generalmethod in the future. As a result, WARN_ON_ONCE will be triggered. AsAlexei suggested, remove the WARN_ON_ONCE first.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38516 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: qcom: msm: mark certain pins as invalid for interruptsOn some platforms, the UFS-reset pin has no interrupt logic in TLMM butis nevertheless registered as a GPIO in the kernel. This enables theuser-space to trigger a BUG() in the pinctrl-msm driver by running, forexample: `gpiomon -c 0 113` on RB2.The exact culprit is requesting pins whose intr_detection_width settingis not 1 or 2 for interrupts. This hits a BUG() inmsm_gpio_irq_set_type(). Potentially crashing the kernel due to aninvalid request from user-space is not optimal, so let's go through thepins and mark those that would fail the check as invalid for the irq chipas we should not even register them as available irqs.This function can be extended if we determine that there are morecorner-cases like this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38535 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY modeWhen transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the codeassumed that the regulator should be disabled. However, if the regulatoris marked as always-on, regulator_is_enabled() continues to return true,leading to an incorrect attempt to disable a regulator which is notenabled.This can result in warnings such as:[ 250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004_regulator_disable+0xe4/0x1a0[ 250.155652] unbalanced disables for VIN_SYS_5V0To fix this, we move the regulator control logic intotegra186_xusb_padctl_id_override() function since it's directly relatedto the ID override state. The regulator is now only disabled when the roletransitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_IDregister. This ensures that regulator enable/disable operations areproperly balanced and only occur when actually transitioning to/from hostmode.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38540 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP CamerasThe Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C)report a HID sensor interface that is not actually implemented.Attempting to access this non-functional sensor via iio_info causessystem hangs as runtime PM tries to wake up an unresponsive sensor.Add these 2 devices to the HID ignore list since the sensor interface isnon-functional by design and should not be exposed to userspace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38548 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (corsair-cpro) Validate the size of the received input bufferAdd buffer_recv_size to store the size of the received bytes.Validate buffer_recv_size in send_usb_cmd().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38550 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: Delay put pmc->idev in mld_del_delrec()pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec()does, the reference should be put after ip6_mc_clear_src() return.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-38712 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()When the volume header contains erroneous values that do not reflectthe actual state of the filesystem, hfsplus_fill_super() assumes thatthe attributes file is not yet created, which later results in hittingBUG_ON() when hfsplus_create_attributes_file() is called. Replace thisBUG_ON() with -EIO error with a message to suggest running fsck tool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-39728 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: samsung: Fix UBSAN panic in samsung_clk_init()With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due todereferencing `ctx->clk_data.hws` before setting`ctx->clk_data.num = nr_clks`. Move that up to fix the crash. UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP Call trace: samsung_clk_init+0x110/0x124 (P) samsung_clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_init_declare+0x28/0x60 ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-39794 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ARM: tegra: Use I/O memcpy to write to IRAMKasan crashes the kernel trying to check boundaries when using thenormal memcpy.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-39795 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: avoid possible overflow for chunk_sectors check in blk_stack_limits()In blk_stack_limits(), we check that the t->chunk_sectors value is amultiple of the t->physical_block_size value.However, by finding the chunk_sectors value in bytes, we may overflowthe unsigned int which holds chunk_sectors, so change the check to bebased on sectors.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-39883 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memoryWhen I did memory failure tests, below panic occurs:page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))kernel BUG at include/linux/page-flags.h:616!Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTICPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40RIP: 0010:unpoison_memory+0x2f3/0x590RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffbR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffeFS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0Call Trace: unpoison_memory+0x2f3/0x590 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110 debugfs_attr_write+0x42/0x60 full_proxy_write+0x5b/0x80 vfs_write+0xd5/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f08f0314887RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffffR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00 Modules linked in: hwpoison_inject---[ end trace 0000000000000000 ]---RIP: 0010:unpoison_memory+0x2f3/0x590RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffbR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffeFS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0Kernel panic - not syncing: Fatal exceptionKernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)---[ end Kernel panic - not syncing: Fatal exception ]---The root cause is that unpoison_memory() tries to check the PG_HWPoisonflags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) istriggered. This can be reproduced by below steps:1.Offline memory block: echo offline > /sys/devices/system/memory/memory12/state2.Get offlined memory pfn: page-types -b n -rlN3.Write pfn to unpoison-pfn echo > /sys/kernel/debug/hwpoison/unpoison-pfnThis scenario can be identified by pfn_to_online_page() returning NULL. And ZONE_DEVICE pages are never expected, so we can simply fail ifpfn_to_online_page() == NULL to fix the bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-39989 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mce: use is_copy_from_user() to determine copy-from-user contextPatch series "mm/hwpoison: Fix regressions in memory failure handling",v4.## 1. What am I trying to do:This patchset resolves two critical regressions related to memory failurehandling that have appeared in the upstream kernel since version 5.17, ascompared to 5.10 LTS. - copyin case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetching in user space## 2. What is the expected outcome and why- For copyin case:Kernel can recover from poison found where kernel is doing get_user() orcopy_from_user() if those places get an error return and the kernel return-EFAULT to the process instead of crashing. More specifily, MCE handlerchecks the fixup handler type to decide whether an in kernel #MC can berecovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery codespecified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.- For instr case:If a poison found while instruction fetching in user space, full recoveryis possible. User process takes #PF, Linux allocates a new page and fillsby reading from storage.## 3. What actually happens and why- For copyin case: kernel panic since v5.17Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a newextable fixup type, EX_TYPE_EFAULT_REG, and later patches updated theextable fixup type for copy-from-user operations, changing it fromEX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESShandling when posion found in get_user() or copy_from_user().- For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE raceWhen an uncorrected memory error is consumed there is a race between theCMCI from the memory controller reporting an uncorrected error with a UCNAsignature, and the core reporting and SRAR signature machine check whenthe data is about to be consumed.### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]Prior to Icelake memory controllers reported patrol scrub events thatdetected a previously unseen uncorrected error in memory by signaling abroadcast machine check with an SRAO (Software Recoverable ActionOptional) signature in the machine check bank. This was overkill becauseit's not an urgent problem that no core is on the verge of consuming thatbad data. It's also found that multi SRAO UCE may cause nested MCEinterrupts and finally become an IERR.Hence, Intel downgrades the machine check bank signature of patrol scrubfrom SRAO to UCNA (Uncorrected, No Action required), and signal changed to#CMCI. Just to add to the confusion, Linux does take an action (inuc_decode_notifier()) to try to offline the page despite the UC*NA*signature name.### Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1]Having decided that CMCI/UCNA is the best action for patrol scrub errors,the memory controller uses it for reads too. But the memory controller isexecuting asynchronously from the core, and can't tell the differencebetween a "real" read and a speculative read. So it will do CMCI/UCNA ifan error is found in any read.Thus:1) Core is clever and thinks address A is needed soon, issues a speculative read.2) Core finds it is going to use address A soon after sending the read request3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A.Quite often (because speculation has got better) the CMCI from the memorycontroller is delivered before the core is committed to the instructionreading address A, so the interrupt is taken, and Linux offlines the page(marking it as poison).## Why user process is killed for instr caseCommit 046545a661af ("mm/hwpoison: fix error page recovered but reported"not---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-40010 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix potential null pointer dereference in afs_put_serverafs_put_server() accessed server->debug_id before the NULL check, whichcould lead to a null pointer dereference. Move the debug_id assignment,ensuring we never dereference a NULL server pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-40030 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: check the return value of pinmux_ops::get_function_name()While the API contract in docs doesn't specify it explicitly, thegeneric implementation of the get_function_name() callback from structpinmux_ops - pinmux_generic_get_function_name() - can fail and returnNULL. This is already checked in pinmux_check_ops() so add a similarcheck in pinmux_func_name_to_selector() instead of passing the returnedpointer right down to strcmp() where the NULL can get dereferenced. Thisis normal operation when adding new pinfunctions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-40097 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: Fix missing pointer check in hda_component_manager_init functionThe __component_match_add function may assign the 'matchptr' pointerthe value ERR_PTR(-ENOMEM), which will subsequently be dereferenced.The call stack leading to the error looks like this:hda_component_manager_init|-> component_match_add |-> component_match_add_release |-> __component_match_add ( ... ,**matchptr, ... ) |-> *matchptr = ERR_PTR(-ENOMEM); // assign|-> component_master_add_with_match( ... match) |-> component_match_realloc(match, match->num); // dereferenceAdd IS_ERR() check to prevent the crash.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-40106 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: fix divide-by-zero in comedi_buf_munge()The comedi_buf_munge() function performs a modulo operation`async->munge_chan %= async->cmd.chanlist_len` without firstchecking if chanlist_len is zero. If a user program submits a command withchanlist_len set to zero, this causes a divide-by-zero error when the deviceprocesses data in the interrupt handler path.Add a check for zero chanlist_len at the beginning of thefunction, similar to the existing checks for !map andCMDF_RAWDATA flag. When chanlist_len is zero, updatemunge_count and return early, indicating the data washandled without munging.This prevents potential kernel panics from malformed user commands.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-40325 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: wait barrier before returning discard request with REQ_NOWAITraid10_handle_discard should wait barrier before returning a discard biowhich has REQ_NOWAIT. And there is no need to print warning calltraceif a discard bio has REQ_NOWAIT flag. Quality engineer usually checksdmesg and reports error if dmesg has warning/error calltrace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-54505 Severity: Moderate CVSS3 score: 5.5

Description: A transient execution vulnerability within AMD CPUs may allow a local user-privileged attacker to leak data via the floating point divisor unit, potentially resulting in loss of confidentiality.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-68191 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udp_tunnel: use netdev_warn() instead of netdev_WARN()netdev_WARN() uses WARN/WARN_ON to print a backtrace along withfile and line information. In this case, udp_tunnel_nic_register()returning an error is just a failed operation, not a kernel bug.udp_tunnel_nic_register() can fail due to a memory allocationfailure (kzalloc() or udp_tunnel_nic_alloc()).This is a normal runtime error and not a kernel bug.Replace netdev_WARN() with netdev_warn() accordingly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.26.1).

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-68767 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: Verify inode mode when loading from disksyzbot is reporting that S_IFMT bits of inode->i_mode can become bogus whenthe S_IFMT bits of the 16bits "mode" field loaded from disk are corrupted.According to [1], the permissions field was treated as reserved in Mac OS8 and 9. According to [2], the reserved field was explicitly initializedwith 0, and that field must remain 0 as long as reserved. Therefore, whenthe "mode" field is not 0 (i.e. no longer reserved), the file must beS_IFDIR if dir == 1, and the file must be one of S_IFREG/S_IFLNK/S_IFCHR/S_IFBLK/S_IFIFO/S_IFSOCK if dir == 0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-68783 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-mixer: us16x08: validate meter packet indicesget_meter_levels_from_urb() parses the 64-byte meter packets sent bythe device and fills the per-channel arrays meter_level[],comp_level[] and master_level[] in struct snd_us16x08_meter_store.Currently the function derives the channel index directly from themeter packet (MUB2(meter_urb, s) - 1) and uses it to index thosearrays without validating the range. If the packet contains anegative or out-of-range channel number, the driver may write pastthe end of these arrays.Introduce a local channel variable and validate it before updating thearrays. We reject negative indices, limit meter_level[] andcomp_level[] to SND_US16X08_MAX_CHANNELS, and guard master_level[]updates with ARRAY_SIZE(master_level).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-68808 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: initialize local pointers upon transfer of memory ownershipvidtv_channel_si_init() creates a temporary list (program, service, event)and ownership of the memory itself is transferred to the PAT/SDT/EITtables through vidtv_psi_pat_program_assign(),vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign().The problem here is that the local pointer where the memory ownershiptransfer was completed is not initialized to NULL. This causes thevidtv_psi_pmt_create_sec_for_each_pat_entry() function to fail, andin the flow that jumps to free_eit, the memory that was freed byvidtv_psi_*_table_destroy() can be accessed again byvidtv_psi_*_event_destroy() due to the uninitialized local pointer, so itis freed once again.Therefore, to prevent use-after-free and double-free vulnerability,local pointers must be initialized to NULL when transferring memoryownership.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-68822 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: alps - fix use-after-free bugs caused by dev3_register_workThe dev3_register_work delayed work item is initialized withinalps_reconnect() and scheduled upon receipt of the first barePS/2 packet from an external PS/2 device connected to the ALPStouchpad. During device detachment, the original implementationcalls flush_workqueue() in psmouse_disconnect() to ensurecompletion of dev3_register_work. However, the flush_workqueue()in psmouse_disconnect() only blocks and waits for work items thatwere already queued to the workqueue prior to its invocation. Anywork items submitted after flush_workqueue() is called are notincluded in the set of tasks that the flush operation awaits.This means that after flush_workqueue() has finished executing,the dev3_register_work could still be scheduled. Although thepsmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),the scheduling of dev3_register_work remains unaffected.The race condition can occur as follows:CPU 0 (cleanup path) | CPU 1 (delayed work)psmouse_disconnect() | psmouse_set_state() | flush_workqueue() | alps_report_bare_ps2_packet() alps_disconnect() | psmouse_queue_work() kfree(priv); // FREE | alps_register_bare_ps2_mouse() | priv = container_of(work...); // USE | priv->dev3 // USEAdd disable_delayed_work_sync() in alps_disconnect() to ensurethat dev3_register_work is properly canceled and prevented fromexecuting after the alps_data structure has been deallocated.This bug is identified by static analysis.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71078 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/64s/slb: Fix SLB multihit issue during SLB preloadOn systems using the hash MMU, there is a software SLB preload cache thatmirrors the entries loaded into the hardware SLB buffer. This preloadcache is subject to periodic eviction - typically after every 256 contextswitches - to remove old entry.To optimize performance, the kernel skips switch_mmu_context() inswitch_mm_irqs_off() when the prev and next mm_struct are the same.However, on hash MMU systems, this can lead to inconsistencies betweenthe hardware SLB and the software preload cache.If an SLB entry for a process is evicted from the software cache on oneCPU, and the same process later runs on another CPU without executingswitch_mmu_context(), the hardware SLB may retain stale entries. If thekernel then attempts to reload that entry, it can trigger an SLBmulti-hit error.The following timeline shows how stale SLB entries are created and cancause a multi-hit error when a process moves between CPUs without aMMU context switch.CPU 0 CPU 1----- -----Process Pexec swapper/1 load_elf_binary begin_new_exc activate_mm switch_mm_irqs_off switch_mmu_context switch_slb /* * This invalidates all * the entries in the HW * and setup the new HW * SLB entries as per the * preload cache. */context_switchsched_migrate_task migrates process P to cpu-1Process swapper/0 context switch (to process P)(uses mm_struct of Process P) switch_mm_irqs_off() switch_slb load_slb++ /* * load_slb becomes 0 here * and we evict an entry from * the preload cache with * preload_age(). We still * keep HW SLB and preload * cache in sync, that is * because all HW SLB entries * anyways gets evicted in * switch_slb during SLBIA. * We then only add those * entries back in HW SLB, * which are currently * present in preload_cache * (after eviction). */ load_elf_binary continues... setup_new_exec() slb_setup_new_exec() sched_switch event sched_migrate_task migrates process P to cpu-0context_switch from swapper/0 to Process P switch_mm_irqs_off() /* * Since both prev and next mm struct are same we don't call * switch_mmu_context(). This will cause the HW SLB and SW preload * cache to go out of sync in preload_new_slb_context. Because there * was an SLB entry which was evicted from both HW and preload cache * on cpu-1. Now later in preload_new_slb_context(), when we will try * to add the same preload entry again, we will add this to the SW * preload cache and then will add it to the HW SLB. Since on cpu-0 * this entry was never invalidated, hence adding this entry to the HW * SLB will cause a SLB multi-hit error. */load_elf_binary cont---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71082 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: revert use of devm_kzalloc in btusbThis reverts commit 98921dbd00c4e ("Bluetooth: Use devm_kzalloc inbtusb.c file").In btusb_probe(), we use devm_kzalloc() to allocate the btusb data. Thisties the lifetime of all the btusb data to the binding of a driver toone interface, INTF. In a driver that binds to other interfaces, ISOCand DIAG, this is an accident waiting to happen.The issue is revealed in btusb_disconnect(), where callingusb_driver_release_interface(&btusb_driver, data->intf) will have devmfree the data that is also being used by the other interfaces of thedriver that may not be released yet.To fix this, revert the use of devm and go back to freeing memoryexplicitly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71083 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/ttm: Avoid NULL pointer deref for evicted BOsIt is possible for a BO to exist that is not currently associated with aresource, e.g. because it has been evicted.When devcoredump tries to read the contents of all BOs for dumping, we needto expect this as well -- in this case, ENODATA is recorded instead of thebuffer contents.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71131 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: seqiv - Do not use req->iv after crypto_aead_encryptAs soon as crypto_aead_encrypt is called, the underlying requestmay be freed by an asynchronous completion. Thus dereferencingreq->iv after it returns is invalid.Instead of checking req->iv against info, create a new variableunaligned_info and use it for that purpose instead.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71183 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: always detect conflicting inodes when logging inode refsAfter rename exchanging (either with the rename exchange operation orregular renames in multiple non-atomic steps) two inodes and at leastone of them is a directory, we can end up with a log tree that containsonly of the inodes and after a power failure that can result in an attemptto delete the other inode when it should not because it was not deletedbefore the power failure. In some case that delete attempt fails whenthe target inode is a directory that contains a subvolume inside it, sincethe log replay code is not prepared to deal with directory entries thatpoint to root items (only inode items).1) We have directories "dir1" (inode A) and "dir2" (inode B) under the same parent directory;2) We have a file (inode C) under directory "dir1" (inode A);3) We have a subvolume inside directory "dir2" (inode B);4) All these inodes were persisted in a past transaction and we are currently at transaction N;5) We rename the file (inode C), so at btrfs_log_new_name() we update inode C's last_unlink_trans to N;6) We get a rename exchange for "dir1" (inode A) and "dir2" (inode B), so after the exchange "dir1" is inode B and "dir2" is inode A. During the rename exchange we call btrfs_log_new_name() for inodes A and B, but because they are directories, we don't update their last_unlink_trans to N;7) An fsync against the file (inode C) is done, and because its inode has a last_unlink_trans with a value of N we log its parent directory (inode A) (through btrfs_log_all_parents(), called from btrfs_log_inode_parent()).8) So we end up with inode B not logged, which now has the old name of inode A. At copy_inode_items_to_log(), when logging inode A, we did not check if we had any conflicting inode to log because inode A has a generation lower than the current transaction (created in a past transaction);9) After a power failure, when replaying the log tree, since we find that inode A has a new name that conflicts with the name of inode B in the fs tree, we attempt to delete inode B... this is wrong since that directory was never deleted before the power failure, and because there is a subvolume inside that directory, attempting to delete it will fail since replay_dir_deletes() and btrfs_unlink_inode() are not prepared to deal with dir items that point to roots instead of inodes. When that happens the mount fails and we get a stack trace like the following: [87.2314] BTRFS info (device dm-0): start tree-log replay [87.2318] BTRFS critical (device dm-0): failed to delete reference to subvol, root 5 inode 256 parent 259 [87.2332] ------------[ cut here ]------------ [87.2338] BTRFS: Transaction aborted (error -2) [87.2346] WARNING: CPU: 1 PID: 638968 at fs/btrfs/inode.c:4345 __btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2368] Modules linked in: btrfs loop dm_thin_pool (...) [87.2470] CPU: 1 UID: 0 PID: 638968 Comm: mount Tainted: G W 6.18.0-rc7-btrfs-next-218+ #2 PREEMPT(full) [87.2489] Tainted: [W]=WARN [87.2494] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [87.2514] RIP: 0010:__btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2538] Code: c0 89 04 24 (...) [87.2568] RSP: 0018:ffffc0e741f4b9b8 EFLAGS: 00010286 [87.2574] RAX: 0000000000000000 RBX: ffff9d3ec8a6cf60 RCX: 0000000000000000 [87.2582] RDX: 0000000000000002 RSI: ffffffff84ab45a1 RDI: 00000000ffffffff [87.2591] RBP: ffff9d3ec8a6ef20 R08: 0000000000000000 R09: ffffc0e741f4b840 [87.2599] R10: ffff9d45dc1fffa8 R11: 0000000000000003 R12: ffff9d3ee26d77e0 [87.2608] R13: ffffc0e741f4ba98 R14: ffff9d4458040800 R15: ffff9d44b6b7ca10 [87.2618] FS: 00007f7b9603a840(0000) GS:ffff9d4658982000(0000) knlGS:0000000000000000 [87.---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71185 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: dma-crossbar: fix device leak on am335x route allocationMake sure to drop the reference taken when looking up the crossbarplatform device during am335x route allocation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71186 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: stm32: dmamux: fix device leak on route allocationMake sure to drop the reference taken when looking up the DMA muxplatform device during route allocation.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:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71224 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: ocb: skip rx_no_sta when interface is not joinedieee80211_ocb_rx_no_sta() assumes a valid channel context, which is onlypresent after JOIN_OCB.RX may run before JOIN_OCB is executed, in which case the OCB interfaceis not operational. Skip RX peer handling when the interface is notjoined to avoid warnings in the RX path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71227 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: don't WARN for connections on invalid channelsIt's not clear (to me) how exactly syzbot managed to hit this,but it seems conceivable that e.g. regulatory changed and hasdisabled a channel between scanning (channel is checked to beusable by cfg80211_get_ies_channel_number) and connecting onthe channel later.With one scenario that isn't covered elsewhere described above,the warning isn't good, replace it with a (more informative)error message.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: Fix potential block overflow that cause system hangWhen a user executes the FITRIM command, an underflow can occur whencalculating nblocks if end_block is too small. Since nblocks is oftype sector_t, which is u64, a negative nblocks value will become avery large positive integer. This ultimately leads to the block layerfunction __blkdev_issue_discard() taking an excessively long time toprocess the bio chain, and the ns_segctor_sem lock remains held for along period. This prevents other tasks from acquiring the ns_segctor_semlock, resulting in the hang reported by syzbot in [1].If the ending block is too small, typically if it is smaller than 4KiBrange, depending on the usage of the segment 0, it may be possible toattempt a discard request beyond the device size causing the hang.Exiting successfully and assign the discarded size (0 in this case)to range->len.Although the start and len values in the user input range are too small,a conservative strategy is adopted here to safely ignore them, which isequivalent to a no-op; it will not perform any trimming and will notthrow an error.[1]task:segctord state:D stack:28968 pid:6093 tgid:6093 ppid:2 task_flags:0x200040 flags:0x00080000Call Trace: rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272 nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline] nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684[ryusuke: corrected part of the commit message about the consequences]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71268 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix reservation leak in some error paths when inserting inline extentIf we fail to allocate a path or join a transaction, we return from__cow_file_range_inline() without freeing the reserved qgroup data,resulting in a leak. Fix this by ensuring we call btrfs_qgroup_free_data()in such cases.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71273 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band()Simplify the code by using device managed memory allocations.This also fixes a memory leak in rtw_register_hw(). The supported bandswere not freed in the error path.Copied from commit 145df52a8671 ("wifi: rtw89: Convertrtw89_core_set_supported_band to use devm_*").

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71274 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rpmsg: core: fix race in driver_override_show() and use core helperThe driver_override_show function reads the driver_override stringwithout holding the device_lock. However, the store function modifiesand frees the string while holding the device_lock. This creates a racecondition where the string can be freed by the store function whilebeing read by the show function, leading to a use-after-free.To fix this, replace the rpmsg_string_attr macro with explicit show andstore functions. The new driver_override_store uses the standarddriver_set_override helper. Since the introduction ofdriver_set_override, the comments in include/linux/rpmsg.h have statedthat this helper must be used to set or clear driver_override, but theimplementation was not updated until now.Because driver_set_override modifies and frees the string while holdingthe device_lock, the new driver_override_show now correctly holds thedevice_lock during the read operation to prevent the race.Additionally, since rpmsg_string_attr has only ever been used fordriver_override, removing the macro simplifies the code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71287 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:memory: mtk-smi: fix device leak on larb probeMake sure to drop the reference taken when looking up the SMI deviceduring larb probe on late probe failure (e.g. probe deferral) and ondriver unbind.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71297 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: 8822b: Avoid WARNING in rtw8822b_config_trx_mode()rtw8822b_set_antenna() can be called from userspace when the chip ispowered off. In that case a WARNING is triggered inrtw8822b_config_trx_mode() because trying to read the RF registerswhen the chip is powered off returns an unexpected value.Call rtw8822b_config_trx_mode() in rtw8822b_set_antenna() only whenthe chip is powered on.------------[ cut here ]------------write RF mode table failWARNING: CPU: 0 PID: 7183 at rtw8822b.c:824 rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b]CPU: 0 UID: 0 PID: 7183 Comm: iw Tainted: G W OE 6.17.5-arch1-1 #1 PREEMPT(full) 01c39fc421df2af799dd5e9180b572af860b40c1Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: LENOVO 82KR/LNVNB161216, BIOS HBCN18WW 08/27/2021RIP: 0010:rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b]Call Trace: rtw8822b_set_antenna+0x57/0x70 [rtw88_8822b 370206f42e5890d8d5f48eb358b759efa37c422b] rtw_ops_set_antenna+0x50/0x80 [rtw88_core 711c8fb4f686162be4625b1d0b8e8c6a5ac850fb] ieee80211_set_antenna+0x60/0x100 [mac80211 f1845d85d2ecacf3b71867635a050ece90486cf3] nl80211_set_wiphy+0x384/0xe00 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? netdev_run_todo+0x63/0x550 genl_family_rcv_msg_doit+0xfc/0x160 genl_rcv_msg+0x1aa/0x2b0 ? __pfx_nl80211_pre_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_nl80211_set_wiphy+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_nl80211_post_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda] ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x59/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x285/0x3c0 ? __alloc_skb+0xdb/0x1a0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x39f/0x3d0 ? import_iovec+0x2f/0x40 ___sys_sendmsg+0x99/0xe0 ? refill_obj_stock+0x12e/0x240 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x81/0x970 ? do_syscall_64+0x81/0x970 ? ksys_read+0x73/0xf0 ? do_syscall_64+0x81/0x970 ? 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+0x76/0x7e ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71313 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: Add missing NULL check for alloc_workqueue()alloc_workqueue() can return NULL on memory allocation failure. Withoutproper error checking, this may lead to a NULL pointer dereference whenqueue_work() is later called with the NULL workqueue pointer inepf_ntb_epc_init().Add a NULL check immediately after alloc_workqueue() and return -ENOMEM onfailure to prevent the driver from loading with an invalid workqueuepointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2025-71315 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vkms: Convert to DRM's vblank timerReplace vkms' vblank timer with the DRM implementation. The DRMcode is identical in concept, but differs in implementation.Vblank timers are covered in vblank helpers and initializer macros,so remove the corresponding hrtimer in struct vkms_output. Thevblank timer calls vkms' custom timeout code via handle_vblank_timeoutin struct drm_crtc_helper_funcs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23049 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panelThe connector type for the DataImage SCF0700C48GGU18 panel is missing anddevm_drm_panel_bridge_add() requires connector type to be set. This leadsto a warning and a backtrace in the kernel log and panel does not work:"WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8"The warning is triggered by a check for valid connector type indevm_drm_panel_bridge_add(). If there is no valid connector typeset for a panel, the warning is printed and panel is not added.Fill in the missing connector type to fix the warning and makethe panel operational once again.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23063 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:uacce: ensure safe queue release with state managementDirectly calling `put_queue` carries risks since it cannotguarantee that resources of `uacce_queue` have been fully releasedbeforehand. So adding a `stop_queue` operation for theUACCE_CMD_PUT_Q command and leaving the `put_queue` operation tothe final resource release ensures safety.Queue states are defined as follows:- UACCE_Q_ZOMBIE: Initial state- UACCE_Q_INIT: After opening `uacce`- UACCE_Q_STARTED: After `start` is issued via `ioctl`When executing `poweroff -f` in virt while accelerator are stillworking, `uacce_fops_release` and `uacce_remove` may executeconcurrently. This can cause `uacce_put_queue` within`uacce_fops_release` to access a NULL `ops` pointer. Therefore, addstate checks to prevent accessing freed pointers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23071 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:regmap: Fix race condition in hwspinlock irqsave routinePreviously, the address of the shared member '&map->spinlock_flags' waspassed directly to 'hwspin_lock_timeout_irqsave'. This creates a racecondition where multiple contexts contending for the lock could overwritethe shared flags variable, potentially corrupting the state for thecurrent lock owner.Fix this by using a local stack variable 'flags' to store the IRQ statetemporarily.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23091 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:intel_th: fix device leak on output open()Make sure to drop the reference taken when looking up the th deviceduring output device open() on errors and on close().Note that a recent commit fixed the leak in a couple of open() errorpaths but not all of them, and the reference is still leaking onsuccessful open().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23095 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gue: Fix skb memleak with inner IP protocol 0.syzbot reported skb memleak below. [0]The repro generated a GUE packet with its inner protocol 0.gue_udp_recv() returns -guehdr->proto_ctype for "resubmit"in ip_protocol_deliver_rcu(), but this only works withnon-zero protocol number.Let's drop such packets.Note that 0 is a valid number (IPv6 Hop-by-Hop Option).I think it is not practical to encap HOPOPT in GUE, so oncesomeone starts to complain, we could pass down a resubmitflag pointer to distinguish two zeros from the upper layer: * no error * resubmit HOPOPT[0]BUG: memory leakunreferenced object 0xffff888109695a00 (size 240): comm "syz.0.17", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): 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] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 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-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23096 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:uacce: fix cdev handling in the cleanup pathWhen cdev_device_add fails, it internally releases the cdev memory,and if cdev_device_del is then executed, it will cause a hang error.To fix it, we check the return value of cdev_device_add() and clearuacce->cdev to avoid calling cdev_device_del in the uacce_remove.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23097 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:migrate: correct lock ordering for hugetlb file foliosSyzbot has found a deadlock (analyzed by Lance Yang):1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock).2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquirefolio_lock.migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)!hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock!The migration path is the one taking locks in the wrong order according tothe documentation at the top of mm/rmap.c. So expand the scope of theexisting i_mmap_lock to cover the calls to remove_migration_ptes() too.This is (mostly) how it used to be after commit c0d0381ade79. That wasremoved by 336bf30eb765 for both file & anon hugetlb pages when it shouldonly have been removed for anon hugetlb pages.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23099 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: limit BOND_MODE_8023AD to Ethernet devicesBOND_MODE_8023AD makes sense for ARPHRD_ETHER only.syzbot reported: BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline] BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full)Tainted: [L]=SOFTLOCKUPHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025Call 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 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hw_addr_create net/core/dev_addr_lists.c:63 [inline] __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 __dev_mc_add net/core/dev_addr_lists.c:868 [inline] dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886 bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180 do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __sys_sendmsg+0x164/0x220 net/socket.c:2678 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307 do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332 entry_SYSENTER_compat_after_hwframe+0x84/0x8e The buggy address belongs to the variable: lacpdu_mcast_addr+0x0/0x40

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23101 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:leds: led-class: Only Add LED to leds_list when it is fully readyBefore this change the LED was added to leds_list before led_init_core()gets called adding it the list before led_classdev.set_brightness_work getsinitialized.This leaves a window where led_trigger_register() of a LED's defaulttrigger will call led_trigger_set() which calls led_set_brightness()which in turn will end up queueing the *uninitialized*led_classdev.set_brightness_work.This race gets hit by the lenovo-thinkpad-t14s EC driver which registers2 LEDs with a default trigger provided by snd_ctl_led.ko in quicksuccession. The first led_classdev_register() causes an async modprobe ofsnd_ctl_led to run and that async modprobe manages to exactly hitthe window where the second LED is on the leds_list without led_init_core()being called for it, resulting in: ------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998Close the race window by moving the adding of the LED to leds_list toafter the led_init_core() call.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23113 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loopCurrently this is checked before running the pending work. Normally thisis quite fine, as work items either end up blocking (which will create anew worker for other items), or they complete fairly quickly. But syzbotreports an issue where io-wq takes seemingly forever to exit, and with abit of debugging, this turns out to be because it queues a bunch of big(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn'tsupport ->read_iter(), loop_rw_iter() ends up handling them. Each readreturns 16MB of data read, which takes 20 (!!) seconds. With a bunch ofthese pending, processing the whole chain can take a long time. Easilylonger than the syzbot uninterruptible sleep timeout of 140 seconds.This then triggers a complaint off the io-wq exit path:INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump."echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000Call Trace: context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fa02738f749RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000caRAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98There's really nothing wrong here, outside of processing these readswill take a LONG time. However, we can speed up the exit by checking theIO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot willexit the ring after queueing up all of these reads. Then once the firstitem is processed, io-wq will simply cancel the rest. That should avoidsyzbot running into this complaint again.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23118 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix data-race warning and potential load/store tearingFix the following: BUG: KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packetwhich is reporting an issue with the reads and writes to ->last_tx_at in: conn->peer->last_tx_at = ktime_get_seconds();and: keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;The lockless accesses to these to values aren't actually a problem as theread only needs an approximate time of last transmission for the purposesof deciding whether or not the transmission of a keepalive packet iswarranted yet.Also, as ->last_tx_at is a 64-bit value, tearing can occur on a 32-bitarch.Fix both of these by switching to an unsigned int for ->last_tx_at and onlystoring the LSW of the time64_t. It can then be reconstructed at needprovided no more than 68 years has elapsed since the last transmission.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23119 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: provide a net pointer to __skb_flow_dissect()After 3cbf4ffba5ee ("net: plumb network namespace into __skb_flow_dissect")we have to provide a net pointer to __skb_flow_dissect(),either via skb->dev, skb->sk, or a user provided pointer.In the following case, syzbot was able to cook a bare skb.WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053Call Trace: bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline] __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline] bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [inline] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf kernel/bpf/syscall.c:6272 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23120 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: avoid one data-race in l2tp_tunnel_del_work()We should read sk->sk_socket only when dealing with kernel sockets.syzbot reported the following data-race:BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_releasewrite to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7fread to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246value changed: 0xffff88811b818000 -> 0x0000000000000000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23125 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INITA null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH keyinitialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127The issue is triggered when sctp_auth_asoc_init_active_key() fails insctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, thecommand sequence is currently:- SCTP_CMD_PEER_INIT- SCTP_CMD_TIMER_STOP (T1_INIT)- SCTP_CMD_TIMER_START (T1_COOKIE)- SCTP_CMD_NEW_STATE (COOKIE_ECHOED)- SCTP_CMD_ASSOC_SHKEY- SCTP_CMD_GEN_COOKIE_ECHOIf SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, whileasoc->peer.auth_capable and asoc->peer.peer_chunks have already been set bySCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULLto be queued by sctp_datamsg_from_user().Since command interpretation stops on failure, no COOKIE_ECHO should beensent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has alreadybeen started, and it may enqueue a COOKIE_ECHO into the outqueue later. Asa result, the DATA chunk can be transmitted together with the COOKIE_ECHOin sctp_outq_flush_data(), leading to the observed issue.Similar to the other places where it calls sctp_auth_asoc_init_active_key()right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEYimmediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and startingT1_COOKIE. This ensures that if shared key generation fails, authenticatedDATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,giving the client another chance to process INIT_ACK and retry key setup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23126 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: fix a race issue related to the operation on bpf_bound_progs listThe netdevsim driver lacks a protection mechanism for operations on thebpf_bound_progs list. When the nsim_bpf_create_prog() performslist_add_tail, it is possible that nsim_bpf_destroy_prog() issimultaneously performs list_del. Concurrent operations on the list maylead to list corruption and trigger a kernel crash as follows:[ 417.290971] kernel BUG at lib/list_debug.c:62![ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI[ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1[ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 417.291007] Workqueue: events bpf_prog_free_deferred[ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0[ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8[ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246[ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000[ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180[ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003[ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20[ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000[ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000[ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0[ 417.291088] PKRU: 55555554[ 417.291091] Call Trace:[ 417.291096] [ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim][ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80[ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0[ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0[ 417.291178] process_one_work+0x18a/0x3a0[ 417.291188] worker_thread+0x27b/0x3a0[ 417.291197] ? __pfx_worker_thread+0x10/0x10[ 417.291207] kthread+0xe5/0x120[ 417.291214] ? __pfx_kthread+0x10/0x10[ 417.291221] ret_from_fork+0x31/0x50[ 417.291230] ? __pfx_kthread+0x10/0x10[ 417.291236] ret_from_fork_asm+0x1a/0x30[ 417.291246] Add a mutex lock, to prevent simultaneous addition and deletion operationson the list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23138 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Add recursion protection in kernel stack trace recordingA bug was reported about an infinite recursion caused by tracing the rcuevents with the kernel stack trace trigger enabled. The stack trace codecalled back into RCU which then called the stack trace again.Expand the ftrace recursion protection to add a set of bits to protectevents from recursion. Each bit represents the context that the event isin (normal, softirq, interrupt and NMI).Have the stack trace code use the interrupt context to protect againstrecursion.Note, the bug showed an issue in both the RCU code as well as the tracingstacktrace code. This only handles the tracing stack trace side of thebug. The RCU fix will be handled separately.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23141 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: send: check for inline extents in range_is_hole_in_parent()Before accessing the disk_bytenr field of a file extent item we needto check if we are dealing with an inline extent.This is because for inline extents their data starts at the offset ofthe disk_bytenr field. So accessing the disk_bytenrmeans we are accessing inline data or in case the inline data is lessthan 8 bytes we can actually cause an invalidmemory access if this inline extent item is the first item in the leafor access metadata from other items.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23154 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix segmentation of forwarding fraglist GROThis patch enhances GSO segment handling by properly checkingthe SKB_GSO_DODGY flag for frag_list GSO packets, addressinglow throughput issues observed when a station accesses IPv4servers via hotspots with an IPv6-only upstream interface.Specifically, it fixes a bug in GSO segmentation when forwardingGRO packets containing a frag_list. The function skb_segment_listcannot correctly process GRO skbs that have been converted by XLAT,since XLAT only translates the header of the head skb. Consequently,skbs in the frag_list may remain untranslated, resulting in protocolinconsistencies and reduced throughput.To address this, the patch explicitly sets the SKB_GSO_DODGY flagfor GSO packets in XLAT's IPv4/IPv6 protocol translation helpers(bpf_skb_proto_4_to_6 and bpf_skb_proto_6_to_4). This marks GSOpackets as potentially modified after protocol translation. As aresult, GSO segmentation will avoid using skb_segment_list andinstead falls back to skb_segment for packets with the SKB_GSO_DODGYflag. This ensures that only safe and fully translated frag_listpackets are processed by skb_segment_list, resolving protocolinconsistencies and improving throughput when forwarding GRO packetsconverted by XLAT.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23157 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not strictly require dirty metadata threshold for metadata writepages[BUG]There is an internal report that over 1000 processes arewaiting at the io_schedule_timeout() of balance_dirty_pages(), causinga system hang and trigger a kernel coredump.The kernel is v6.4 kernel based, but the root problem still applies toany upstream kernel before v6.18.[CAUSE]From Jan Kara for his wisdom on the dirty page balance behavior first. This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB. Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there's dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying. When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit. So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in that cgroup.So that means the only way to reduce the dirty pages of that cgroup isto writeback the dirty pages of btrfs btree inode, and only after thatthose processes can exit balance_dirty_pages().Now back to the btrfs part, btree_writepages() is responsible forwriting back dirty btree inode pages.The problem here is, there is a btrfs internal threshold that if thebtree inode's dirty bytes are below the 32M threshold, it will notdo any writeback.This behavior is to batch as much metadata as possible so we won't writeback those tree blocks and then later re-COW them again for anothermodification.This internal 32MiB is higher than the existing dirty page size (28MiB),meaning no writeback will happen, causing a deadlock between btrfs andcgroup:- Btrfs doesn't want to write back btree inode until more dirty pages- Cgroup/MM doesn't want more dirty pages for btrfs btree inode Thus any process touching that btree inode is put into sleep until the number of dirty pages is reduced.Thanks Jan Kara a lot for the analysis of the root cause.[ENHANCEMENT]Since kernel commit b55102826d7d ("btrfs: set AS_KERNEL_FILE on thebtree_inode"), btrfs btree inode pages will only be charged to the rootcgroup which should have a much larger limit than btrfs' 32MiBthreshold.So it should not affect newer kernels.But for all current LTS kernels, they are all affected by this problem,and backporting the whole AS_KERNEL_FILE may not be a good idea.Even for newer kernels I still think it's a good idea to getrid of the internal threshold at btree_writepages(), since for most casescgroup/MM has a better view of full system memory usage than btrfs' fixedthreshold.For internal callers using btrfs_btree_balance_dirty() since thatfunction is already doing internal threshold check, we don't need tobother them.But for external callers of btree_writepages(), just respect theirrequests and write back whatever they want, ignoring the internalbtrfs threshold to avoid such deadlock on btree inode dirty pagebalancing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23164 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rocker: fix memory leak in rocker_world_port_post_fini()In rocker_world_port_pre_init(), rocker_port->wpriv is allocated withkzalloc(wops->port_priv_size, GFP_KERNEL). However, inrocker_world_port_post_fini(), the memory is only freed whenwops->port_post_fini callback is set: if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv);Since rocker_ofdpa_ops does not implement port_post_fini callback(it is NULL), the wpriv memory allocated for each port is never freedwhen ports are removed. This leads to a memory leak ofsizeof(struct ofdpa_port) bytes per port on every device removal.Fix this by always calling kfree(rocker_port->wpriv) regardless ofwhether the port_post_fini callback exists.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23167 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: Fix race between rfkill and nci_unregister_device().syzbot reported the splat below [0] without a repro.It indicates that struct nci_dev.cmd_wq had been destroyed beforenci_close_device() was called via rfkill.nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which(I think) was called from virtual_ncidev_close() when syzbot close()dan fd of virtual_ncidev.The problem is that nci_unregister_device() destroys nci_dev.cmd_wqfirst and then calls nfc_unregister_device(), which removes thedevice from rfkill by rfkill_unregister().So, the device is still visible via rfkill even after nci_dev.cmd_wqis destroyed.Let's unregister the device from rfkill first in nci_unregister_device().Note that we cannot call nfc_unregister_device() beforenci_close_device() because 1) nfc_unregister_device() calls device_del() which frees all memory allocated by devm_kzalloc() and linked to ndev->conn_info_list 2) nci_rx_work() could try to queue nci_conn_info to ndev->conn_info_list which could be leakedThus, nfc_unregister_device() is split into two functions so wecan remove rfkill interfaces only before nci_close_device().[0]:DEBUG_LOCKS_WARN_ON(1)WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349Modules linked in:CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline]RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187Code: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1fRSP: 0018:ffffc9000c767680 EFLAGS: 00010046RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0Call Trace: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ksys_write+0x150/0x270 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fa59b39acb9Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9RDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007RBP: 00007fa59b408bf7 R08: ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23176 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: toshiba_haps: Fix memory leaks in add/remove routinestoshiba_haps_add() leaks the haps object allocated by it if it returnsan error after allocating that object successfully.toshiba_haps_remove() does not free the object pointed to bytoshiba_haps before clearing that pointer, so it becomes unreachableallocated memory.Address these memory leaks by using devm_kzalloc() for allocatingthe memory in question.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23182 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: tegra: Fix a memory leak in tegra_slink_probe()In tegra_slink_probe(), when platform_get_irq() fails, it directlyreturns from the function with an error code, which causes a memory leak.Replace it with a goto label to ensure proper cleanup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23190 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: amd: fix memory leak in acp3x pdm dma ops

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23216 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()In iscsit_dec_conn_usage_count(), the function calls complete() whileholding the conn->conn_usage_lock. As soon as complete() is invoked, thewaiter (such as iscsit_close_connection()) may wake up and proceed to freethe iscsit_conn structure.If the waiter frees the memory before the current thread reachesspin_unlock_bh(), it results in a KASAN slab-use-after-free as the functionattempts to release a lock within the already-freed connection structure.Fix this by releasing the spinlock before calling complete().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: classmate-laptop: Add missing NULL pointer checksIn a few places in the Classmate laptop driver, code using the accelobject may run before that object's address is stored in the driverdata of the input device using it.For example, cmpc_accel_sensitivity_store_v4() is the "show" methodof cmpc_accel_sensitivity_attr_v4 which is added in cmpc_accel_add_v4(),before calling dev_set_drvdata() for inputdev->dev. If the sysfsattribute is accessed prematurely, the dev_get_drvdata(&inputdev->dev)call in in cmpc_accel_sensitivity_store_v4() returns NULL whichleads to a NULL pointer dereference going forward.Moreover, sysfs attributes using the input device are added beforeinitializing that device by cmpc_add_acpi_notify_device() and if oneof them is accessed before running that function, a NULL pointerdereference will occur.For example, cmpc_accel_sensitivity_attr_v4 is added before callingcmpc_add_acpi_notify_device() and if it is read prematurely, thedev_get_drvdata(&acpi->dev) call in cmpc_accel_sensitivity_show_v4()returns NULL which leads to a NULL pointer dereference going forward.Fix this by adding NULL pointer checks in all of the relevant places.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23242 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Fix potential NULL pointer dereference in header processingIf siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(),qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data()dereferences qp->rx_fpdu->more_ddp_segs without checking, whichmay lead to a NULL pointer deref. Only check more_ddp_segs whenrx_fpdu is present.KASAN splat:[ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7][ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23247 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: secure_seq: add back ports to TS offsetThis reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")tcp_tw_recycle went away in 2017.Zhouyan Deng reported off-path TCP source port leakage viaSYN cookie side-channel that can be fixed in multiple ways.One of them is to bring back TCP ports in TS offset randomization.As a bonus, we perform a single siphash() computationto provide both an ISN and a TS offset.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23253 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-core: fix wrong reinitialization of ringbuffer on reopendvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens theDVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), whichreinitializes the waitqueue list head to empty.Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of thesame DVR device share it), this orphans any existing waitqueue entriesfrom io_uring poll or epoll, leaving them with stale prev/next pointerswhile the list head is reset to {self, self}.The waitqueue and spinlock in dvr_buffer are already properlyinitialized once in dvb_dmxdev_init(). The open path only needs toreset the buffer data pointer, size, and read/write positions.Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with directassignment of data/size and a call to dvb_ringbuffer_reset(), whichproperly resets pread, pwrite, and error with correct memory orderingwithout touching the waitqueue or spinlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23256 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: liquidio: Fix off-by-one error in VF setup_nic_devices() cleanupIn setup_nic_devices(), the initialization loop jumps to the labelsetup_nic_dev_free on failure. The current cleanup loop while(i--)skip the failing index i, causing a memory leak.Fix this by changing the loop to iterate from the current index idown to 0.Compile tested only. Issue found using code review.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23257 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: liquidio: Fix off-by-one error in PF setup_nic_devices() cleanupIn setup_nic_devices(), the initialization loop jumps to the labelsetup_nic_dev_free on failure. The current cleanup loop while(i--)skip the failing index i, causing a memory leak.Fix this by changing the loop to iterate from the current index idown to 0.Also, decrement i in the devlink_alloc failure path to point to thelast successfully allocated index.Compile tested only. Issue found using code review.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23264 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Revert "drm/amd: Check if ASPM is enabled from PCIe subsystem"This reverts commit 7294863a6f01248d72b61d38478978d638641bee.This commit was erroneously applied again after commit 0ab5d711ec74("drm/amd: Refactor `amdgpu_aspm` to be evaluated per device")removed it, leading to very hard to debug crashes, when used with a system with twoAMD GPUs of which only one supports ASPM.(cherry picked from commit 97a9689300eb2b393ba5efc17c8e5db835917080)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23289 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq()Fix a user triggerable leak on the system call failure path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23291 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: properly drop the usb interface reference on disconnectWhen the device is disconnected from the driver, there is a "dangling"reference count on the usb interface that was grabbed in the probecallback. Fix this up by properly dropping the reference after we aredone with it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23300 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthopWhen a standalone IPv6 nexthop object is created with a loopback device(e.g., "ip -6 nexthop add id 100 dev lo"), fib6_nh_init() misclassifiesit as a reject route. This is because nexthop objects have no destinationprefix (fc_dst=::), causing fib6_is_reject() to match any loopbacknexthop. The reject path skips fib_nh_common_init(), leavingnhc_pcpu_rth_output unallocated. If an IPv4 route later references thisnexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output andpanics.Simplify the check in fib6_nh_init() to only match explicit rejectroutes (RTF_REJECT) instead of using fib6_is_reject(). The loopbackpromotion heuristic in fib6_is_reject() is handled separately byip6_route_info_create_nh(). After this change, the three cases behaveas follows:1. Explicit reject route ("ip -6 route add unreachable 2001:db8::/64"): RTF_REJECT is set, enters reject path, skips fib_nh_common_init(). No behavior change.2. Implicit loopback reject route ("ip -6 route add 2001:db8::/32 dev lo"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. ip6_route_info_create_nh() still promotes it to reject afterward. nhc_pcpu_rth_output is allocated but unused, which is harmless.3. Standalone nexthop object ("ip -6 nexthop add id 100 dev lo"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. nhc_pcpu_rth_output is properly allocated, fixing the crash when IPv4 routes reference this nexthop.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23302 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: annotate data-races around sk->sk_{data_ready,write_space}skmsg (and probably other layers) are changing these pointerswhile other cpus might read them concurrently.Add corresponding READ_ONCE()/WRITE_ONCE() annotationsfor UDP, TCP and AF_UNIX.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23303 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Don't log plaintext credentials in cifs_set_cifscredsWhen debug logging is enabled, cifs_set_cifscreds() logs the keypayload and exposes the plaintext username and password. Remove thedebug log to avoid exposing credentials.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23315 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: Fix possible oob access in mt76_connac2_mac_write_txwi_80211()Check frame length before accessing the mgmt fields inmt76_connac2_mac_write_txwi_80211 in order to avoid a possible oobaccess.[fix check to also cover mgmt->u.action.u.addba_req.capab,correct Fixes tag]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23318 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Use correct version for UAC3 header validationThe entry of the validators table for UAC3 AC header descriptor isdefined with the wrong protocol version UAC_VERSION_2, while it shouldhave been UAC_VERSION_3. This results in the validator never matchingfor actual UAC3 devices (protocol == UAC_VERSION_3), causing theirheader descriptors to bypass validation entirely. A malicious USBdevice presenting a truncated UAC3 header could exploit this to causeout-of-bounds reads when the driver later accesses unvalidateddescriptor fields.The bug was introduced in the same commit as the recently fixed UAC3feature unit sub-type typo, and appears to be from the same copy-pasteerror when the UAC3 section was created from the UAC2 section.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23336 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: cancel rfkill_block work in wiphy_unregister()There is a use-after-free error in cfg80211_shutdown_all_interfaces foundby syzkaller:BUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220Read of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326CPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: events cfg80211_rfkill_block_workCall Trace: dump_stack_lvl+0x116/0x1f0 print_report+0xcd/0x630 kasan_report+0xe0/0x110 cfg80211_shutdown_all_interfaces+0x213/0x220 cfg80211_rfkill_block_work+0x1e/0x30 process_one_work+0x9cf/0x1b70 worker_thread+0x6c8/0xf10 kthread+0x3c5/0x780 ret_from_fork+0x56d/0x700 ret_from_fork_asm+0x1a/0x30 The problem arises due to the rfkill_block work is not cancelled when wiphyis being unregistered. In order to fix the issue cancel the correspondingwork in wiphy_unregister().Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23348 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cxl: Fix race of nvdimm_bus object when creating nvdimm objectsFound issue during running of cxl-translate.sh unit test. Adding a 3ssleep right before the test seems to make the issue reproduce fairlyconsistently. The cxl_translate module has dependency on cxl_acpi andcauses orphaned nvdimm objects to reprobe after cxl_acpi is removed.The nvdimm_bus object is registered by the cxl_nvb object whencxl_acpi_probe() is called. With the nvdimm_bus object missing,__nd_device_register() will trigger NULL pointer dereference whenaccessing the dev->parent that points to &nvdimm_bus->dev.[ 192.884510] BUG: kernel NULL pointer dereference, address: 000000000000006c[ 192.895383] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20250812-19.fc42 08/12/2025[ 192.897721] Workqueue: cxl_port cxl_bus_rescan_queue [cxl_core][ 192.899459] RIP: 0010:kobject_get+0xc/0x90[ 192.924871] Call Trace:[ 192.925959] [ 192.926976] ? pm_runtime_init+0xb9/0xe0[ 192.929712] __nd_device_register.part.0+0x4d/0xc0 [libnvdimm][ 192.933314] __nvdimm_create+0x206/0x290 [libnvdimm][ 192.936662] cxl_nvdimm_probe+0x119/0x1d0 [cxl_pmem][ 192.940245] cxl_bus_probe+0x1a/0x60 [cxl_core][ 192.943349] really_probe+0xde/0x380This patch also relies on the previous change wheredevm_cxl_add_nvdimm_bridge() is called from drivers/cxl/pmem.c insteadof drivers/cxl/core.c to ensure the dependency of cxl_acpi on cxl_pmem.1. Set probe_type of cxl_nvb to PROBE_FORCE_SYNCHRONOUS to ensure the driver is probed synchronously when add_device() is called.2. Add a check in __devm_cxl_add_nvdimm_bridge() to ensure that the cxl_nvb driver is attached during cxl_acpi_probe().3. Take the cxl_root uport_dev lock and the cxl_nvb->dev lock in devm_cxl_add_nvdimm() before checking nvdimm_bus is valid.4. Set cxl_nvdimm flag to CXL_NVD_F_INVALIDATED so cxl_nvdimm_probe() will exit with -EBUSY.The removal of cxl_nvdimm devices should prevent any orphaned devicesfrom probing once the nvdimm_bus is gone.[ dj: Fixed 0-day reported kdoc issue. ][ dj: Fix cxl_nvb reference leak on error. Gregory (kreview-0811365) ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23352 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/efi: defer freeing of boot services memoryefi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODEand EFI_BOOT_SERVICES_DATA using memblock_free_late().There are two issue with that: memblock_free_late() should be used formemory allocated with memblock_alloc() while the memory reserved withmemblock_reserve() should be freed with free_reserved_area().More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=yefi_free_boot_services() is called before deferred initialization of thememory map is complete.Benjamin Herrenschmidt reports that this causes a leak of ~140MB ofRAM on EC2 t3a.nano instances which only have 512MB or RAM.If the freed memory resides in the areas that memory map for them isstill uninitialized, they won't be actually freed becausememblock_free_late() calls memblock_free_pages() and the latter skipsuninitialized pages.Using free_reserved_area() at this point is also problematic because__free_page() accesses the buddy of the freed page and that again mightend up in uninitialized part of the memory map.Delaying the entire efi_free_boot_services() could be problematicbecause in addition to freeing boot services memory it updatesefi.memmap without any synchronization and that's undesirable late inboot when there is concurrency.More robust approach is to only defer freeing of the EFI boot servicesmemory.Split efi_free_boot_services() in two. First efi_unmap_boot_services()collects ranges that should be freed into an array thenefi_free_boot_services() later frees them after deferred init is complete.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23368 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: register phy led_triggers during probe to avoid AB-BA deadlockThere is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV andLED_TRIGGER_PHY are enabled:[ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc <-- Trying to get lock "triggers_list_lock" via down_write(&triggers_list_lock);[ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234[ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c[ 1362.065489] [<80651fc4>] phylink_fwnode_phy_connect+0x15c/0x23c[ 1362.071480] [<8066ee18>] mtk_open+0x7c/0xba0[ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0[ 1362.080384] [<806d7668>] __dev_change_flags+0x244/0x24c[ 1362.085598] [<806d7698>] dev_change_flags+0x28/0x78[ 1362.090528] [<807150e4>] dev_ioctl+0x4c0/0x654 <-- Hold lock "rtnl_mutex" by calling rtnl_lock();[ 1362.094985] [<80694360>] sock_ioctl+0x2f4/0x4e0[ 1362.099567] [<802e9c4c>] sys_ioctl+0x32c/0xd8c[ 1362.104022] [<80014504>] syscall_common+0x34/0x58Here LED_TRIGGER_PHY is registering LED triggers during phy_attachwhile holding RTNL and then taking triggers_list_lock.[ 1362.191101] [<806c2640>] register_netdevice_notifier+0x60/0x168 <-- Trying to get lock "rtnl_mutex" via rtnl_lock();[ 1362.197073] [<805504ac>] netdev_trig_activate+0x194/0x1e4[ 1362.202490] [<8054e28c>] led_trigger_set+0x1d4/0x360 <-- Hold lock "triggers_list_lock" by down_read(&triggers_list_lock);[ 1362.207511] [<8054eb38>] led_trigger_write+0xd8/0x14c[ 1362.212566] [<80381d98>] sysfs_kf_bin_write+0x80/0xbc[ 1362.217688] [<8037fcd8>] kernfs_fop_write_iter+0x17c/0x28c[ 1362.223174] [<802cbd70>] vfs_write+0x21c/0x3c4[ 1362.227712] [<802cc0c4>] ksys_write+0x78/0x12c[ 1362.232164] [<80014504>] syscall_common+0x34/0x58Here LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takestriggers_list_lock and then RTNL. A classical AB-BA deadlock.phy_led_triggers_registers() does not require the RTNL, it does notmake any calls into the network stack which require protection. Thereis also no requirement the PHY has been attached to a MAC, thetriggers only make use of phydev state. This allows the call tophy_led_triggers_registers() to be placed elsewhere. PHY probe() andrelease() don't hold RTNL, so solving the AB-BA deadlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23370 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-wmi-sysman: Don't hex dump plaintext password dataset_new_password() hex dumps the entire buffer, which contains plaintextpassword data, including current and new passwords. Remove the hex dumpto avoid leaking credentials.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23372 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: rawsock: cancel tx_work before socket teardownIn rawsock_release(), cancel any pending tx_work and purge the writequeue before orphaning the socket. rawsock_tx_work runs on the systemworkqueue and calls nfc_data_exchange which dereferences the NCIdevice. Without synchronization, tx_work can race with socket anddevice teardown when a process is killed (e.g. by SIGKILL), leadingto use-after-free or leaked references.Set SEND_SHUTDOWN first so that if tx_work is already running it willsee the flag and skip transmitting, then use cancel_work_sync to waitfor any in-progress execution to finish, and finally purge anyremaining queued skbs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23374 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blktrace: fix __this_cpu_read/write in preemptible contexttracing_record_cmdline() internally uses __this_cpu_read() and__this_cpu_write() on the per-CPU variable trace_cmdline_save, andtrace_save_cmdline() explicitly asserts preemption is disabled vialockdep_assert_preemption_disabled(). These operations are only safewhen preemption is off, as they were designed to be called from thescheduler context (probe_wakeup_sched_switch() / probe_wakeup()).__blk_add_trace() was calling tracing_record_cmdline(current) early inthe blk_tracer path, before ring buffer reservation, from processcontext where preemption is fully enabled. This triggers the followingusing blktests/blktrace/002:blktrace/002 (blktrace ftrace corruption with sysfs trace) [failed] runtime 0.367s ... 0.437s something found in dmesg: [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] null_blk: disk nullb1 created [ 81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracing_record_cmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] [ 81.362886] dump_stack_lvl+0x8d/0xb0 ... (See '/mnt/sda/blktests/results/nodev/blktrace/002.dmesg' for the entire message)[ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33[ 81.239580] null_blk: disk nullb1 created[ 81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516[ 81.362842] caller is tracing_record_cmdline+0x10/0x40[ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full)[ 81.362877] Tainted: [N]=TEST[ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014[ 81.362881] Call Trace:[ 81.362884] [ 81.362886] dump_stack_lvl+0x8d/0xb0[ 81.362895] check_preemption_disabled+0xce/0xe0[ 81.362902] tracing_record_cmdline+0x10/0x40[ 81.362923] __blk_add_trace+0x307/0x5d0[ 81.362934] ? lock_acquire+0xe0/0x300[ 81.362940] ? iov_iter_extract_pages+0x101/0xa30[ 81.362959] blk_add_trace_bio+0x106/0x1e0[ 81.362968] submit_bio_noacct_nocheck+0x24b/0x3a0[ 81.362979] ? lockdep_init_map_type+0x58/0x260[ 81.362988] submit_bio_wait+0x56/0x90[ 81.363009] __blkdev_direct_IO_simple+0x16c/0x250[ 81.363026] ? __pfx_submit_bio_wait_endio+0x10/0x10[ 81.363038] ? rcu_read_lock_any_held+0x73/0xa0[ 81.363051] blkdev_read_iter+0xc1/0x140[ 81.363059] vfs_read+0x20b/0x330[ 81.363083] ksys_read+0x67/0xe0[ 81.363090] do_syscall_64+0xbf/0xf00[ 81.363102] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 81.363106] RIP: 0033:0x7f281906029d[ 81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec[ 81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIG_RAX: 0000000000000000[ 81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d[ 81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000[ 81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000[ 81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000[ 81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a[ 81.363142] The same BUG fires from blk_add_trace_plug(), blk_add_trace_unplug(),and blk_add_trace_rq() paths as well.The purpose of tracin---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23379 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: fix divide by zero in the offload pathOffloading ETS requires computing each class' WRR weight: this is done byaveraging over the sums of quanta as 'q_sum' and 'q_psum'. Using unsignedint, the same integer size as the individual DRR quanta, can overflow andeven cause division by zero, like it happened in the following splat: Oops: divide error: 0000 [#1] SMP PTI CPU: 13 UID: 0 PID: 487 Comm: tc Tainted: G E 6.19.0-virtme #45 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Call Trace: ets_qdisc_change+0x870/0xf40 [sch_ets] qdisc_create+0x12b/0x540 tc_modify_qdisc+0x6d7/0xbd0 rtnetlink_rcv_msg+0x168/0x6b0 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x1d6/0x2b0 netlink_sendmsg+0x22e/0x470 ____sys_sendmsg+0x38a/0x3c0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x111/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f440b81c77e Code: 4d 89 d8 e8 d4 bc 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:00007fff951e4c10 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000481820 RCX: 00007f440b81c77e RDX: 0000000000000000 RSI: 00007fff951e4cd0 RDI: 0000000000000003 RBP: 00007fff951e4c20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff951f4fa8 R13: 00000000699ddede R14: 00007f440bb01000 R15: 0000000000486980 Modules linked in: sch_ets(E) netdevsim(E) ---[ end trace 0000000000000000 ]--- RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets] Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44 RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246 RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660 RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000 FS: 00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---Fix this using 64-bit integers for 'q_sum' and 'q_psum'.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23381 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix nd_tbl NULL dereference when IPv6 is disabledWhen booting with the 'ipv6.disable=1' parameter, the nd_tbl is neverinitialized because inet6_init() exits before ndisc_init() is calledwhich initializes it. Then, if neigh_suppress is enabled and an ICMPv6Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() willdereference ipv6_stub->nd_tbl which is NULL, passing it toneigh_lookup(). This causes a kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neigh_lookup+0x16/0xe0 [...] Call Trace: ? neigh_lookup+0x16/0xe0 br_do_suppress_nd+0x160/0x290 [bridge] br_handle_frame_finish+0x500/0x620 [bridge] br_handle_frame+0x353/0x440 [bridge] __netif_receive_skb_core.constprop.0+0x298/0x1110 __netif_receive_skb_one_core+0x3d/0xa0 process_backlog+0xa0/0x140 __napi_poll+0x2c/0x170 net_rx_action+0x2c4/0x3a0 handle_softirqs+0xd0/0x270 do_softirq+0x3f/0x60Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() inthe callers. This is in essence disabling NS/NA suppression when IPv6 isdisabled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23382 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing themIn commit 2ff5baa9b527 ("HID: appleir: Fix potential NULL dereference atraw event handle"), we handle the fact that raw event callbackscan happen even for a HID device that has not been "claimed" causing acrash if a broken device were attempted to be connected to the system.Fix up the remaining in-tree HID drivers that forgot to add this samecheck to resolve the same issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23386 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for QPLIn DQ-QPL mode, gve_tx_clean_pending_packets() incorrectly uses the RDAbuffer cleanup path. It iterates num_bufs times and attempts to unmapentries in the dma array.This leads to two issues:1. The dma array shares storage with tx_qpl_buf_ids (union). Interpreting buffer IDs as DMA addresses results in attempting to unmap incorrect memory locations.2. num_bufs in QPL mode (counting 2K chunks) can significantly exceed the size of the dma array, causing out-of-bounds access warnings(trace below is how we noticed this issue).UBSAN: array-index-out-of-bounds indrivers/net/ethernet/drivers/net/ethernet/google/gve/gve_tx_dqo.c:178:5 index 18 is out ofrange for type 'dma_addr_t[18]' (aka 'unsigned long long[18]')Workqueue: gve gve_service_task [gve]Call Trace:dump_stack_lvl+0x33/0xa0__ubsan_handle_out_of_bounds+0xdc/0x110gve_tx_stop_ring_dqo+0x182/0x200 [gve]gve_close+0x1be/0x450 [gve]gve_reset+0x99/0x120 [gve]gve_service_task+0x61/0x100 [gve]process_scheduled_works+0x1e9/0x380Fix this by properly checking for QPL mode and delegating togve_free_tx_qpl_bufs() to reclaim the buffers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23389 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix memory leak in ice_set_ringparam()In ice_set_ringparam, tx_rings and xdp_rings are allocated beforerx_rings. If the allocation of rx_rings fails, the code jumps tothe done label leaking both tx_rings and xdp_rings. Furthermore, ifthe setup of an individual Rx ring fails during the loop, the code jumpsto the free_tx label which releases tx_rings but leaks xdp_rings.Fix this by introducing a free_xdp label and updating the error paths toensure both xdp_rings and tx_rings are properly freed if rx_ringsallocation or setup fails.Compile tested only. Issue found using a prototype static analysis tooland code review.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23391 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_CT: drop pending enqueued packets on template removalTemplates refer to objects that can go away while packets are sitting innfqueue refer to:- helper, this can be an issue on module removal.- timeout policy, nfnetlink_cttimeout might remove it.The use of templates with zone and event cache filter are safe, sincethis just copies values.Flush these enqueued packets in case the template rule gets removed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23420 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wlcore: Fix a locking bugMake sure that wl->mutex is locked before it is unlocked. This has beendetected by the Clang thread-safety analyzer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23438 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mvpp2: guard flow control update with global_tx_fc in buffer switchingmvpp2_bm_switch_buffers() unconditionally callsmvpp2_bm_pool_update_priv_fc() when switching between per-cpu andshared buffer pool modes. This function programs CM3 flow controlregisters via mvpp2_cm3_read()/mvpp2_cm3_write(), which dereferencepriv->cm3_base without any NULL check.When the CM3 SRAM resource is not present in the device tree (thethird reg entry added by commit 60523583b07c ("dts: marvell: add CM3SRAM memory to cp11x ethernet device tree")), priv->cm3_base remainsNULL and priv->global_tx_fc is false. Any operation that triggersmvpp2_bm_switch_buffers(), for example an MTU change that crossesthe jumbo frame threshold, will crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2_cm3_read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2_bm_pool_update_fc+0x40/0x12c mvpp2_bm_pool_update_priv_fc+0x94/0xd8 mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0 mvpp2_change_mtu+0x140/0x380 __dev_set_mtu+0x1c/0x38 dev_set_mtu_ext+0x78/0x118 dev_set_mtu+0x48/0xa8 dev_ifsioc+0x21c/0x43c dev_ioctl+0x2d8/0x42c sock_ioctl+0x314/0x378Every other flow control call site in the driver already guardshardware access with either priv->global_tx_fc or port->tx_fc.mvpp2_bm_switch_buffers() is the only place that omits this check.Add the missing priv->global_tx_fc guard to both the disable andre-enable calls in mvpp2_bm_switch_buffers(), consistent with therest of the driver.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23439 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=nWhen CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0(success) without actually creating a socket. Callers such asfou_create() then proceed to dereference the uninitialized socketpointer, resulting in a NULL pointer dereference.The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764) [...] Call Trace: genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130)This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, socallers correctly take their error paths. There is only one caller ofthe vulnerable function and only privileged users can trigger it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23444 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failureieee80211_tx_prepare_skb() has three error paths, but only two of themfree the skb. The first error path (ieee80211_tx_prepare() returningTX_DROP) does not free it, while invoke_tx_handlers() failure and thefragmentation check both do.Add kfree_skb() to the first error path so all three are consistent,and remove the now-redundant frees in callers (ath9k, mt76,mac80211_hwsim) to avoid double-free.Document the skb ownership guarantee in the function's kdoc.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23446 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: aqc111: Do not perform PM inside suspend callbacksyzbot reports "task hung in rpm_resume"This is caused by aqc111_suspend callingthe PM variant of its write_cmd routine.The simplified call trace looks like this:rpm_suspend() usb_suspend_both() - here udev->dev.power.runtime_status == RPM_SUSPENDING aqc111_suspend() - called for the usb device interface aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() - here we call rpm_resume() on our parent rpm_resume() - Here we wait for a status change that will never happen.At this point we block another task which holdsrtnl_lock and locks up the whole networking stack.Fix this by replacing the write_cmd calls with their _nopm variants

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-23468 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Limit BO list entry count to prevent resource exhaustionUserspace can pass an arbitrary number of BO list entries via thebo_number field. Although the previous multiplication overflow checkprevents out-of-bounds allocation, a large number of entries could stillcause excessive memory allocation (up to potentially gigabytes) andunnecessarily long list processing times.Introduce a hard limit of 128k entries per BO list, which is more thansufficient for any realistic use case (e.g., a single list containing allbuffers in a large scene). This prevents memory exhaustion attacks andensures predictable performance.Return -EINVAL if the requested entry count exceeds the limit(cherry picked from commit 688b87d39e0aa8135105b40dc167d74b5ada5332)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.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-release == 15.4 (version in image is 15.4-150400.58.10.2).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.37.1).

CVE-2026-25645 Severity: Moderate CVSS3 score: 5.5

Description: Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-requests > 0-0 (version in image is 2.31.0-150400.6.21.1).

CVE-2026-31405 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-net: fix OOB access in ULE extension header tablesThe ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tablesin handle_one_ule_extension() are declared with 255 elements (validindices 0-254), but the index htype is derived from network-controlleddata as (ule_sndu_type & 0x00FF), giving a range of 0-255. Whenhtype equals 255, an out-of-bounds read occurs on the function pointertable, and the OOB value may be called as a function pointer.Add a bounds check on htype against the array size before either tableis accessed. Out-of-range values now cause the SNDU to be discarded.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.222.1 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31411 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: atm: fix crash due to unvalidated vcc pointer in sigd_send()Reproducer available at [1].The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vccpointer from msg->vcc and uses it directly without any validation. Thispointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeefIn normal operation, the kernel sends the vcc pointer to the signalingdaemon via sigd_enq() when processing operations like connect(), bind(),or listen(). The daemon is expected to return the same pointer whenresponding. However, a malicious daemon can send arbitrary pointer values.Fix this by introducing find_get_vcc() which validates the pointer bysearching through vcc_hash (similar to how sigd_close() iterates overall VCCs), and acquires a reference via sock_hold() if found.Since struct atm_vcc embeds struct sock as its first member, they sharethe same lifetime. Therefore using sock_hold/sock_put is sufficient tokeep the vcc alive while it is being used.Note that there may be a race with sigd_close() which could mark the vccwith various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns.However, sock_hold() guarantees the memory remains valid, so this raceonly affects the logical state, not memory safety.[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31414 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_expect: use expect->helperUse expect->helper in ctnetlink and /proc to dump the helper name.Using nfct_help() without holding a reference to the master conntrackis unsafe.Use exp->master->helper in ctnetlink path if userspace does not providean explicit helper when creating an expectation to retain the existingbehaviour. The ctnetlink expectation path holds the reference on themaster conntrack and nf_conntrack_expect lock and the nfnetlink gluepath refers to the master ct that is attached to the skb.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31418 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: drop logically empty buckets in mtype_delmtype_del() counts empty slots below n->pos in k, but it only drops thebucket when both n->pos and k are zero. This misses buckets whose liveentries have all been removed while n->pos still points past deleted slots.Treat a bucket as empty when all positions below n->pos are unused andrelease it directly instead of shrinking it further.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31420 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bridge: mrp: reject zero test interval to avoid OOM panicbr_mrp_start_test() and br_mrp_start_in_test() accept the user-suppliedinterval value from netlink without validation. When interval is 0,usecs_to_jiffies(0) yields 0, causing the delayed work(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to rescheduleitself with zero delay. This creates a tight loop on system_percpu_wqthat allocates and transmits MRP test frames at maximum rate, exhaustingall system memory and causing a kernel panic via OOM deadlock.The same zero-interval issue applies to br_mrp_start_in_test_parse()for interconnect test frames.Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for bothIFLA_BRIDGE_MRP_START_TEST_INTERVAL andIFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at thenetlink attribute parsing layer before the value ever reaches theworkqueue scheduling code. This is consistent with how other bridgesubsystems (br_fdb, br_mst) enforce range constraints on netlinkattributes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31421 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: cls_fw: fix NULL pointer dereference on shared blocksThe old-method path in fw_classify() calls tcf_block_q() anddereferences q->handle. Shared blocks leave block->q NULL, causing aNULL deref when an empty cls_fw filter is attached to a shared blockand a packet with a nonzero major skb mark is classified.Reject the configuration in fw_change() when the old method (noTCA_OPTIONS) is used on a shared block, since fw_classify()'sold-method path needs block->q which is NULL for shared blocks.The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fw_classify (net/sched/cls_fw.c:81) Call Trace: tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860) tc_run (net/core/dev.c:4401) __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31422 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: cls_flow: fix NULL pointer dereference on shared blocksflow_change() calls tcf_block_q() and dereferences q->handle to derivea default baseclass. Shared blocks leave block->q NULL, causing a NULLderef when a flow filter without a fully qualified baseclass is createdon a shared block.Check tcf_block_shared() before accessing block->q and return -EINVALfor shared blocks. This avoids the null-deref shown below:=======================================================================KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]RIP: 0010:flow_change (net/sched/cls_flow.c:508)Call Trace: tc_new_tfilter (net/sched/cls_api.c:2432) rtnetlink_rcv_msg (net/core/rtnetlink.c:6980) [...]=======================================================================

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31423 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_hfsc: fix divide-by-zero in rtsc_min()m2sm() converts a u32 slope to a u64 scaled value. For large inputs(e.g. m1=4000000000), the result can reach 2^32. rtsc_min() storesthe difference of two such u64 values in a u32 variable `dsm` anduses it as a divisor. When the difference is exactly 2^32 thetruncation yields zero, causing a divide-by-zero oops in theconcave-curve intersection path: Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...]Widen `dsm` to u64 and replace do_div() with div64_u64() so the fulldifference is preserved.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31424 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARPWeiming Shi says:xt_match and xt_target structs registered with NFPROTO_UNSPEC can beloaded by any protocol family through nft_compat. When such amatch/target sets .hooks to restrict which hooks it may run on, thebitmask uses NF_INET_* constants. This is only correct for familieswhose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridgeall share the same five hooks (PRE_ROUTING ... POST_ROUTING).ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with differentsemantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooksvalidation silently passes for the wrong reasons, allowing matches torun on ARP chains where the hook assumptions (e.g. state->in beingset on input hooks) do not hold. This leads to NULL pointerdereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) Kernel panic - not syncing: Fatal exception in interruptFix it by restricting arptables to NFPROTO_ARP extensions only.Note that arptables-legacy only supports:- arpt_CLASSIFY- arpt_mangle- arpt_MARKthat provide explicit NFPROTO_ARP match/target declarations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31425 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rds: ib: reject FRMR registration before IB connection is establishedrds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_dataand passes it to rds_ib_reg_frmr() for FRWR memory registration. On afresh outgoing connection, ic is allocated in rds_ib_conn_alloc() withi_cm_id = NULL because the connection worker has not yet calledrds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() withRDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parsesthe control message before any connection establishment, allowingrds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash thekernel.The existing guard in rds_ib_reg_frmr() only checks for !ic (added incommit 9e630bcb7701), which does not catch this case since ic is allocatedearly and is always non-NULL once the connection object exists. KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920 Call Trace: rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167) rds_ib_map_frmr (net/rds/ib_frmr.c:252) rds_ib_reg_frmr (net/rds/ib_frmr.c:430) rds_ib_get_mr (net/rds/ib_rdma.c:615) __rds_rdma_map (net/rds/rdma.c:295) rds_cmsg_rdma_map (net/rds/rdma.c:860) rds_sendmsg (net/rds/send.c:1363) ____sys_sendmsg do_syscall_64Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are allnon-NULL before proceeding with FRMR registration, mirroring the guardalready present in rds_ib_post_inv(). Return -ENODEV when the connectionis not ready, which the existing error handling in rds_cmsg_send() convertsto -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() tostart the connection worker.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31428 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD__build_packet_message() manually constructs the NFULA_PAYLOAD netlinkattribute using skb_put() and skb_copy_bits(), bypassing the standardnla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytesare allocated (including NLA alignment padding), only data_len bytesof actual packet data are copied. The trailing nla_padlen(data_len)bytes (1-3 when data_len is not 4-byte aligned) are never initialized,leaking stale heap contents to userspace via the NFLOG netlink socket.Replace the manual attribute construction with nla_reserve(), whichhandles the tailroom check, header setup, and padding zeroing via__nla_reserve(). The subsequent skb_copy_bits() fills in the payloaddata on top of the properly initialized attribute.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31447 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: reject mount if bigalloc with s_first_data_block != 0bigalloc with s_first_data_block != 0 is not supported, reject mountingit.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31449 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: validate p_idx bounds in ext4_ext_correct_indexesext4_ext_correct_indexes() walks up the extent tree correctingindex entries when the first extent in a leaf is modified. Beforeaccessing path[k].p_idx->ei_block, there is no validation thatp_idx falls within the valid range of index entries for thatlevel.If the on-disk extent header contains a corrupted or craftedeh_entries value, p_idx can point past the end of the allocatedbuffer, causing a slab-out-of-bounds read.Fix this by validating path[k].p_idx against EXT_LAST_INDEX() atboth access sites: before the while loop and inside it. Return-EFSCORRUPTED if the index pointer is out of range, consistentwith how other bounds violations are handled in the ext4 extenttree code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31450 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: publish jinode after initializationext4_inode_attach_jinode() publishes ei->jinode to concurrent users.It used to set ei->jinode before jbd2_journal_init_jbd_inode(),allowing a reader to observe a non-NULL jinode with i_vfs_inodestill unset.The fast commit flush path can then pass this jinode tojbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping andmay crash.Below is the crash I observe:```BUG: unable to handle page fault for address: 000000010beb47f4PGD 110e51067 P4D 110e51067 PUD 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014RIP: 0010:xas_find_marked+0x3d/0x2e0Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ecR10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0PKRU: 55555554Call Trace:filemap_get_folios_tag+0x87/0x2a0__filemap_fdatawait_range+0x5f/0xd0? srso_alias_return_thunk+0x5/0xfbef5? __schedule+0x3e7/0x10c0? srso_alias_return_thunk+0x5/0xfbef5? srso_alias_return_thunk+0x5/0xfbef5? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80? srso_alias_return_thunk+0x5/0xfbef5? cap_safe_nice+0x37/0x70? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80? srso_alias_return_thunk+0x5/0xfbef5filemap_fdatawait_range_keep_errors+0x12/0x40ext4_fc_commit+0x697/0x8b0? ext4_file_write_iter+0x64b/0x950? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80? srso_alias_return_thunk+0x5/0xfbef5? vfs_write+0x356/0x480? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80ext4_sync_file+0xf7/0x370do_fsync+0x3b/0x80? syscall_trace_enter+0x108/0x1d0__x64_sys_fdatasync+0x16/0x20do_syscall_64+0x62/0x2c0entry_SYSCALL_64_after_hwframe+0x76/0x7e...```Fix this by initializing the jbd2_inode first.Use smp_wmb() and WRITE_ONCE() to publish ei->jinode afterinitialization. Readers use READ_ONCE() to fetch the pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31453 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: avoid dereferencing log items after push callbacksAfter xfsaild_push_item() calls iop_push(), the log item may have beenfreed if the AIL lock was dropped during the push. Background inodereclaim or the dquot shrinker can free the log item while the AIL lockis not held, and the tracepoints in the switch statement dereferencethe log item after iop_push() returns.Fix this by capturing the log item type, flags, and LSN before callingxfsaild_push_item(), and introducing a new xfs_ail_push_class traceevent class that takes these pre-captured values and the ailp pointerinstead of the log item pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31454 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: save ailp before dropping the AIL lock in push callbacksIn xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the AIL lockis dropped to perform buffer IO. Once the cluster buffer no longerprotects the log item from reclaim, the log item may be freed bybackground reclaim or the dquot shrinker. The subsequent spin_lock()call dereferences lip->li_ailp, which is a use-after-free.Fix this by saving the ailp pointer in a local variable while the AILlock is held and the log item is guaranteed to be valid.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31455 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: stop reclaim before pushing AIL during unmountThe unmount sequence in xfs_unmount_flush_inodes() pushed the AIL whilebackground reclaim and inodegc are still running. This is brokenindependently of any use-after-free issues - background reclaim andinodegc should not be running while the AIL is being pushed duringunmount, as inodegc can dirty and insert inodes into the AIL during theflush, and background reclaim can race to abort and free dirty inodes.Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel backgroundreclaim before pushing the AIL. Stop inodegc before cancellingm_reclaim_work because the inodegc worker can re-queue m_reclaim_workvia xfs_inodegc_set_reclaimable.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31462 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: prevent immediate PASID reuse casePASID resue could cause interrupt issue when processimmediately runs into hw state left by previousprocess exited with the same PASID, it's possible thatpage faults are still pending in the IH ring buffer whenthe process exits and frees up its PASID. To prevent thecase, it uses idr cyclic allocator same as kernel pid's.(cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31467 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: add GFP_NOIO in the bio completion if neededThe bio completion path in the process context (e.g. dm-verity)will directly call into decompression rather than trigger anotherworkqueue context for minimal scheduling latencies, which canthen call vm_map_ram() with GFP_KERNEL.Due to insufficient memory, vm_map_ram() may generate memoryswapping I/O, which can cause submit_bio_wait to deadlockin some scenarios.Trimmed down the call stack, as follows:f2fs_submit_read_io submit_bio //bio_list is initialized. mmc_blk_mq_recovery z_erofs_endio vm_map_ram __pte_alloc_kernel __alloc_pages_direct_reclaim shrink_folio_list __swap_writepage submit_bio_wait //bio_list is non-NULL, hang!!!Use memalloc_noio_{save,restore}() to wrap up this path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31474 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: isotp: fix tx.buf use-after-free in isotp_sendmsg()isotp_sendmsg() uses only cmpxchg() on so->tx.state to serialize accessto so->tx.buf. isotp_release() waits for ISOTP_IDLE viawait_event_interruptible() and then calls kfree(so->tx.buf).If a signal interrupts the wait_event_interruptible() inside close()while tx.state is ISOTP_SENDING, the loop exits early and releaseproceeds to force ISOTP_SHUTDOWN and continues to kfree(so->tx.buf)while sendmsg may still be reading so->tx.buf for the final CAN framein isotp_fill_dataframe().The so->tx.buf can be allocated once when the standard tx.buf length needsto be extended. Move the kfree() of this potentially extended tx.buf tosk_destruct time when either isotp_sendmsg() and isotp_release() are done.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31486 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (pmbus/core) Protect regulator operations with mutexThe regulator operations pmbus_regulator_get_voltage(),pmbus_regulator_set_voltage(), and pmbus_regulator_list_voltage()access PMBus registers and shared data but were not protected bythe update_lock mutex. This could lead to race conditions.However, adding mutex protection directly to these functions causesa deadlock because pmbus_regulator_notify() (which callsregulator_notifier_call_chain()) is often called with the mutexalready held (e.g., from pmbus_fault_handler()). If a regulatorcallback then calls one of the now-protected voltage functions,it will attempt to acquire the same mutex.Rework pmbus_regulator_notify() to utilize a worker function tosend notifications outside of the mutex protection. Events arestored as atomics in a per-page bitmask and processed by the worker.Initialize the worker and its associated data during regulatorregistration, and ensure it is cancelled on device removal usingdevm_add_action_or_reset().While at it, remove the unnecessary include of linux/of.h.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31491 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Harden depth calculation functionsAn issue was exposed where OS can pass in U32_MAX for SQ/RQ/SRQ size.This can cause integer overflow and truncation of SQ/RQ/SRQ depthreturning a success when it should have failed.Harden the functions to do all depth calculations and boundarychecking in u64 sizes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31492 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Initialize free_qp completion before using itIn irdma_create_qp, if ib_copy_to_udata fails, it will callirdma_destroy_qp to clean up which will attempt to wait onthe free_qp completion, which is not initialized yet. Fix thisby initializing the completion before the ib_copy_to_udata call.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31495 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: use netlink policy range checksReplace manual range and mask validations with netlink policyannotations in ctnetlink code paths, so that the netlink core rejectsinvalid values early and can generate extack errors.- CTA_PROTOINFO_TCP_STATE: reject values > TCP_CONNTRACK_SYN_SENT2 at policy level, removing the manual >= TCP_CONNTRACK_MAX check.- CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values > TCP_MAX_WSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count.- CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with CTA_FILTER_F_ALL, removing the manual mask checks.- CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding a new mask define grouping all valid expect flags.Extracted from a broader nf-next patch by Florian Westphal, scoped toctnetlink for the fixes tree.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31497 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: clamp SCO altsetting table indicesbtusb_work() maps the number of active SCO links to USB alternatesettings through a three-entry lookup table when CVSD traffic usestransparent voice settings. The lookup currently indexes alts[] withdata->sco_num - 1 without first constraining sco_num to the number ofavailable table entries.While the table only defines alternate settings for up to three SCOlinks, data->sco_num comes from hci_conn_num() and is used directly.Cap the lookup to the last table entry before indexing it so thedriver keeps selecting the highest supported alternate setting withoutreading past alts[].

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31510 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cbBefore using sk pointer, check if it is null.Fix the following: KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267] CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025 Workqueue: events l2cap_info_timeout RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce veth0_macvtap: entered promiscuous mode RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: __kasan_check_byte+0x12/0x40 lock_acquire+0x79/0x2e0 lock_sock_nested+0x48/0x100 ? l2cap_sock_ready_cb+0x46/0x160 l2cap_sock_ready_cb+0x46/0x160 l2cap_conn_start+0x779/0xff0 ? __pfx_l2cap_conn_start+0x10/0x10 ? l2cap_info_timeout+0x60/0xa0 ? __pfx___mutex_lock+0x10/0x10 l2cap_info_timeout+0x68/0xa0 ? process_scheduled_works+0xa8d/0x18c0 process_scheduled_works+0xb6e/0x18c0 ? __pfx_process_scheduled_works+0x10/0x10 ? assign_work+0x3d5/0x5e0 worker_thread+0xa53/0xfc0 kthread+0x388/0x470 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x51e/0xb90 ? __pfx_ret_from_fork+0x10/0x10 veth1_macvtap: entered promiscuous mode ? __switch_to+0xc7d/0x1450 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- batman_adv: batadv0: Interface activated: batadv_slave_0 batman_adv: batadv0: Interface activated: batadv_slave_1 netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce ieee80211 phy39: Selected rate control algorithm 'minstrel_ht' RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31519 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol createWe have recently observed a number of subvolumes with broken dentries.ls-ing the parent dir looks like:drwxrwxrwt 1 root root 16 Jan 23 16:49 .drwxr-xr-x 1 root root 24 Jan 23 16:48 ..d????????? ? ? ? ? ? broken_subvoland similarly stat-ing the file fails.In this state, deleting the subvol fails with ENOENT, but attempting tocreate a new file or subvol over it errors out with EEXIST and evenaborts the fs. Which leaves us a bit stuck.dmesg contains a single notable error message reading:"could not do orphan cleanup -2"2 is ENOENT and the error comes from the failure handling path ofbtrfs_orphan_cleanup(), with the stack leading back up tobtrfs_lookup().btrfs_lookupbtrfs_lookup_dentrybtrfs_orphan_cleanup // prints that message and returns -ENOENTAfter some detailed inspection of the internal state, it became clearthat:- there are no orphan items for the subvol- the subvol is otherwise healthy looking, it is not half-deleted or anything, there is no drop progress, etc.- the subvol was created a while ago and does the meaningful first btrfs_orphan_cleanup() call that sets BTRFS_ROOT_ORPHAN_CLEANUP much later.- after btrfs_orphan_cleanup() fails, btrfs_lookup_dentry() returns -ENOENT, which results in a negative dentry for the subvolume via d_splice_alias(NULL, dentry), leading to the observed behavior. The bug can be mitigated by dropping the dentry cache, at which point we can successfully delete the subvolume if we want.i.e.,btrfs_lookup() btrfs_lookup_dentry() if (!sb_rdonly(inode->vfs_inode)->vfs_inode) btrfs_orphan_cleanup(sub_root) test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP) btrfs_search_slot() // finds orphan item for inode N ... prints "could not do orphan cleanup -2" if (inode == ERR_PTR(-ENOENT)) inode = NULL; return d_splice_alias(NULL, dentry) // NEGATIVE DENTRY for valid subvolumebtrfs_orphan_cleanup() does test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP)on the root when it runs, so it cannot run more than once on a givenroot, so something else must run concurrently. However, the obviousroutes to deleting an orphan when nlinks goes to 0 should not be able torun without first doing a lookup into the subvolume, which should runbtrfs_orphan_cleanup() and set the bit.The final important observation is that create_subvol() callsd_instantiate_new() but does not set BTRFS_ROOT_ORPHAN_CLEANUP, so ifthe dentry cache gets dropped, the next lookup into the subvolume willmake a real call into btrfs_orphan_cleanup() for the first time. Thisopens up the possibility of concurrently deleting the inode/orphan itemsbut most typical evict() paths will be holding a reference on the parentdentry (child dentry holds parent->d_lockref.count via dget ind_alloc(), released in __dentry_kill()) and prevent the parent frombeing removed from the dentry cache.The one exception is delayed iputs. Ordered extent creation callsigrab() on the inode. If the file is unlinked and closed while thoserefs are held, iput() in __dentry_kill() decrements i_count but doesnot trigger eviction (i_count > 0). The child dentry is freed and thesubvol dentry's d_lockref.count drops to 0, making it evictable whilethe inode is still alive.Since there are two races (the race between writeback and unlink andthe race between lookup and delayed iputs), and there are too many movingparts, the following three diagrams show the complete picture.(Only the second and third are races)Phase 1:Create Subvol in dentry cache without BTRFS_ROOT_ORPHAN_CLEANUP setbtrfs_mksubvol() lookup_one_len() __lookup_slow() d_alloc_parallel() __d_alloc() // d_lockref.count = 1 create_subvol(dentry) // doesn't touch the bit.. d_instantiate_new(dentry, inode) // dentry in cache with d_lockref.c---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31523 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: ensure we're polling a polled queueA user can change the polled queue count at run time. There's a briefwindow during a reset where a hipri task may try to poll that queuebefore the block layer has updated the queue maps, which would race withthe now interrupt driven queue and may cause double completions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31531 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()When querying a nexthop object via RTM_GETNEXTHOP, the kernel currentlyallocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient forsingle nexthops and small Equal-Cost Multi-Path groups, this fixedallocation fails for large nexthop groups like 512 nexthops.This results in the following warning splat: WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608 [...] RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395) [...] Call Trace: rtnetlink_rcv_msg (net/core/rtnetlink.c:6989) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585) ___sys_sendmsg (net/socket.c:2641) __sys_sendmsg (net/socket.c:2671) 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) Fix this by allocating the size dynamically using nh_nlmsg_size() andusing nlmsg_new(), this is consistent with nexthop_notify() behavior. Inaddition, adjust nh_nlmsg_size_grp() so it calculates the size neededbased on flags passed. While at it, also add the size of NHA_FDB fornexthop group size calculation as it was missing too.This cannot be reproduced via iproute2 as the group size is currentlylimited and the command fails as follows:addattr_l ERROR: message exceeded bound of 1048

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31540 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Check set_default_submission() before deferencingWhen the i915 driver firmware binaries are not present, theset_default_submission pointer is not set. This pointer isdereferenced during suspend anyways.Add a check to make sure it is set before dereferencing.[ 23.289926] PM: suspend entry (deep)[ 23.293558] Filesystems sync: 0.000 seconds[ 23.298010] Freezing user space processes[ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds)[ 23.309766] OOM killer disabled.[ 23.313027] Freezing remaining freezable tasks[ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)[ 23.342038] serial 00:05: disabled[ 23.345719] serial 00:02: disabled[ 23.349342] serial 00:01: disabled[ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache[ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache[ 23.361635] ata1.00: Entering standby power mode[ 23.368863] ata2.00: Entering standby power mode[ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 23.452194] #PF: supervisor instruction fetch in kernel mode[ 23.457896] #PF: error_code(0x0010) - not-present page[ 23.463065] PGD 0 P4D 0[ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI[ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary)[ 23.482512] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN[ 23.496511] Workqueue: async async_run_entry_fn[ 23.501087] RIP: 0010:0x0[ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6.[ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246[ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f[ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000[ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff[ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8[ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68[ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000[ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0[ 23.572539] PKRU: 55555554[ 23.575281] Call Trace:[ 23.577770] [ 23.579905] intel_engines_reset_default_submission+0x42/0x60[ 23.585695] __intel_gt_unset_wedged+0x191/0x200[ 23.590360] intel_gt_unset_wedged+0x20/0x40[ 23.594675] gt_sanitize+0x15e/0x170[ 23.598290] i915_gem_suspend_late+0x6b/0x180[ 23.602692] i915_drm_suspend_late+0x35/0xf0[ 23.607008] ? __pfx_pci_pm_suspend_late+0x10/0x10[ 23.611843] dpm_run_callback+0x78/0x1c0[ 23.615817] device_suspend_late+0xde/0x2e0[ 23.620037] async_suspend_late+0x18/0x30[ 23.624082] async_run_entry_fn+0x25/0xa0[ 23.628129] process_one_work+0x15b/0x380[ 23.632182] worker_thread+0x2a5/0x3c0[ 23.635973] ? __pfx_worker_thread+0x10/0x10[ 23.640279] kthread+0xf6/0x1f0[ 23.643464] ? __pfx_kthread+0x10/0x10[ 23.647263] ? __pfx_kthread+0x10/0x10[ 23.651045] ret_from_fork+0x131/0x190[ 23.654837] ? __pfx_kthread+0x10/0x10[ 23.658634] ret_from_fork_asm+0x1a/0x30[ 23.662597] [ 23.664826] Modules linked in:[ 23.667914] CR2: 0000000000000000[ 23.671271] ------------[ cut here ]------------(cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31545 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nxp-nci: allow GPIOs to sleepAllow the firmware and enable GPIOs to sleep.This fixes a `WARN_ON' and allows the driver to operate GPIOs which areconnected to I2C GPIO expanders.-- >8 --kernel: WARNING: CPU: 3 PID: 2636 at drivers/gpio/gpiolib.c:3880 gpiod_set_value+0x88/0x98-- >8 --

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31546 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: bonding: fix NULL deref in bond_debug_rlb_hash_showrlb_clear_slave intentionally keeps RLB hash-table entries onthe rx_hashtbl_used_head list with slave set to NULL when noreplacement slave is available. However, bond_debug_rlb_hash_showvisites client_info->slave without checking if it's NULL.Other used-list iterators in bond_alb.c already handle this NULL-slavestate safely:- rlb_update_client returns early on !client_info->slave- rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalancecompare slave values before visiting- lb_req_update_subnet_clients continues if slave is NULLThe following NULL deref crash can be trigger inbond_debug_rlb_hash_show:[ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41)[ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286[ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204[ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078[ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000[ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0[ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8[ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000[ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0[ 1.295897] Call Trace:[ 1.296134] seq_read_iter (fs/seq_file.c:231)[ 1.296341] seq_read (fs/seq_file.c:164)[ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1))[ 1.296658] vfs_read (fs/read_write.c:572)[ 1.296981] ksys_read (fs/read_write.c:717)[ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))[ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)Add a NULL check and print "(none)" for entries with no assigned slave.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31548 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: cancel pmsr_free_wk in cfg80211_pmsr_wdev_downWhen the nl80211 socket that originated a PMSR request isclosed, cfg80211_release_pmsr() sets the request's nl_portidto zero and schedules pmsr_free_wk to process the abortasynchronously. If the interface is concurrently torn downbefore that work runs, cfg80211_pmsr_wdev_down() callscfg80211_pmsr_process_abort() directly. However, the already-scheduled pmsr_free_wk work item remains pending and may runafter the interface has been removed from the driver. Thiscould cause the driver's abort_pmsr callback to operate on atorn-down interface, leading to undefined behavior andpotential crashes.Cancel pmsr_free_wk synchronously in cfg80211_pmsr_wdev_down()before calling cfg80211_pmsr_process_abort(). This ensures anypending or in-progress work is drained before interface teardownproceeds, preventing the work from invoking the driver abortcallback after the interface is gone.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31549 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: cp2615: fix serial string NULL-deref at probeThe cp2615 driver uses the USB device serial string as the i2c adaptername but does not make sure that the string exists.Verify that the device has a serial number before accessing it to avoidtriggering a NULL-pointer dereference (e.g. with malicious devices).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31551 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Fix static_branch_dec() underflow for aql_disable.syzbot reported static_branch_dec() underflow in aql_enable_write(). [0]The problem is that aql_enable_write() does not serialise concurrentwrite()s to the debugfs.aql_enable_write() checks static_key_false(&aql_disable.key) andlater calls static_branch_inc() or static_branch_dec(), but thestate may change between the two calls.aql_disable does not need to track inc/dec.Let's use static_branch_enable() and static_branch_disable().[0]:val == 0WARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288Modules linked in:CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full)Tainted: [U]=USER, [L]=SOFTLOCKUPHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026RIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 <0f> 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000aR13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0Call Trace: __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline] __static_key_slow_dec kernel/jump_label.c:321 [inline] static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336 aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343 short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383 vfs_write+0x2aa/0x1070 fs/read_write.c:684 ksys_pwrite64 fs/read_write.c:793 [inline] __do_sys_pwrite64 fs/read_write.c:801 [inline] __se_sys_pwrite64 fs/read_write.c:798 [inline] __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f530cf9aeb9Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31557 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet: move async event work off nvmet-wqFor target nvmet_ctrl_free() flushes ctrl->async_event_work.If nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueuecompletion for the same worker:-A. Async event work queued on nvmet-wq (prior to disconnect): nvmet_execute_async_event() queue_work(nvmet_wq, &ctrl->async_event_work) nvmet_add_async_event() queue_work(nvmet_wq, &ctrl->async_event_work)B. Full pre-work chain (RDMA CM path): nvmet_rdma_cm_handler() nvmet_rdma_queue_disconnect() __nvmet_rdma_queue_disconnect() queue_work(nvmet_wq, &queue->release_work) process_one_work() lock((wq_completion)nvmet-wq) <--------- 1st nvmet_rdma_release_queue_work()C. Recursive path (same worker): nvmet_rdma_release_queue_work() nvmet_rdma_free_queue() nvmet_sq_destroy() nvmet_ctrl_put() nvmet_ctrl_free() flush_work(&ctrl->async_event_work) __flush_work() touch_wq_lockdep_map() lock((wq_completion)nvmet-wq) <--------- 2ndLockdep splat: ============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N -------------------------------------------- kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 but task is already holding lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660 3 locks held by kworker/u192:42/44933: #0: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660 #1: ffffc9000e6cbe28 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x660 #2: ffffffff82d4db60 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 Workqueue: nvmet-wq nvmet_rdma_release_queue_work [nvmet_rdma] Call Trace: __flush_work+0x268/0x530 nvmet_ctrl_free+0x140/0x310 [nvmet] nvmet_cq_put+0x74/0x90 [nvmet] nvmet_rdma_free_queue+0x23/0xe0 [nvmet_rdma] nvmet_rdma_release_queue_work+0x19/0x50 [nvmet_rdma] process_one_work+0x206/0x660 worker_thread+0x184/0x320 kthread+0x10c/0x240 ret_from_fork+0x319/0x390Move async event work to a dedicated nvmet-aen-wq to avoid reentrantflush on nvmet-wq.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31560 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: spi-dw-dma: fix print error log when wait finish transactionIf an error occurs, the device may not have a current message. In thiscase, the system will crash.In this case, it's better to use dev from the struct ctlr (struct spi_controller*).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31565 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Fix deadlock during netdev reset with active connectionsResolve deadlock that occurs when user executes netdev reset while RDMAapplications (e.g., rping) are active. The netdev reset causes icedriver to remove irdma auxiliary driver, triggering device_delete andsubsequent client removal. During client removal, uverbs_client waitsfor QP reference count to reach zero while cma_client holds the finalreference, creating circular dependency and indefinite wait in iWARPmode. Skip QP reference count wait during device reset to preventdeadlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31568 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/mm: Add missing secure storage access fixups for donated memoryThere are special cases where secure storage access exceptions happenin a kernel context for pages that don't have the PG_arch_1 bitset. That bit is set for non-exported guest secure storage (memory)but is absent on storage donated to the Ultravisor since the kernelisn't allowed to export donated pages.Prior to this patch we would try to export the page by callingarch_make_folio_accessible() which would instantly return since thearch bit is absent signifying that the page was already exported andno further action is necessary. This leads to secure storage accessexception loops which can never be resolved.With this patch we unconditionally try to export and if that fails wefixup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31576 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: hackrf: fix to not free memory after the device is registered in hackrf_probe()In hackrf driver, the following race condition occurs:``` CPU0 CPU1hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... fd = sys_open("/path/to/dev"); // open hackrf fd .... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... sys_ioctl(fd, ...); v4l2_ioctl(); video_is_registered() // UAF!! .... sys_close(fd); v4l2_release() // UAF!! hackrf_video_release() kfree(); // DFB!!```When a V4L2 or video device is unregistered, the device node is removed sonew open() calls are blocked.However, file descriptors that are already open-and any in-flight I/O-donot terminate immediately; they remain valid until the last reference isdropped and the driver's release() is invoked.Therefore, freeing device memory on the error path after hackrf_probe()has registered dev it will lead to a race to use-after-free vuln, sincethose already-open handles haven't been released yet.And since release() free memory too, race to use-after-free anddouble-free vuln occur.To prevent this, if device is registered from probe(), it should bemodified to free memory only through release() rather than callingkfree() directly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31578 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: as102: fix to not free memory after the device is registered in as102_usb_probe()In as102_usb driver, the following race condition occurs:``` CPU0 CPU1as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); fd = sys_open("/path/to/dev"); // open as102 fd .... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... sys_close(fd); as102_release() // UAF!! as102_usb_release() kfree(); // DFB!!```When a USB character device registered with usb_register_dev() is laterunregistered (via usb_deregister_dev() or disconnect), the device node isremoved so new open() calls fail. However, file descriptors that arealready open do not go away immediately: they remain valid until the lastreference is dropped and the driver's .release() is invoked.In as102, as102_usb_probe() calls usb_register_dev() and then, on anerror path, does usb_deregister_dev() and frees as102_dev_t right away.If userspace raced a successful open() before the deregistration, thatopen FD will later hit as102_release() --> as102_usb_release() and accessor free as102_dev_t again, occur a race to use-after-free anddouble-free vuln.The fix is to never kfree(as102_dev_t) directly once usb_register_dev()has succeeded. After deregistration, defer freeing memory to .release().In other words, let release() perform the last kfree when the final openFD is closed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31579 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exitwg_netns_pre_exit() manually acquires rtnl_lock() inside thepernet .pre_exit callback. This causes a hung task when anotherthread holds rtnl_mutex - the cleanup_net workqueue (or thesetup_net failure rollback path) blocks indefinitely inwg_netns_pre_exit() waiting to acquire the lock.Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net:Add ->exit_rtnl() hook to struct pernet_operations."), where theframework already holds RTNL and batches all callbacks under asingle rtnl_lock()/rtnl_unlock() pair, eliminating the contentionwindow.The rcu_assign_pointer(wg->creating_net, NULL) is safe to movefrom .pre_exit to .exit_rtnl (which runs after synchronize_rcu())because all RCU readers of creating_net either use maybe_get_net()- which returns NULL for a dying namespace with zero refcount - oraccess net->user_ns which remains valid throughout the entireops_undo_list sequence.[ Jason: added __net_exit and __read_mostly annotations that were missing. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31590 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGIONDrop the WARN in sev_pin_memory() on npages overflowing an int, as theWARN is comically trivially to trigger from userspace, e.g. by doing: struct kvm_enc_region range = { .addr = 0, .size = -1ul, }; __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range);Note, the checks in sev_mem_enc_register_region() that presumably exist toverify the incoming address+size are completely worthless, as both "addr"and "size" are u64s and SEV is 64-bit only, i.e. they _can't_ be greaterthan ULONG_MAX. That wart will be cleaned up in the near future. if (range->addr > ULONG_MAX || range->size > ULONG_MAX) return -EINVAL;Opportunistically add a comment to explain why the code calculates thenumber of pages the "hard" way, e.g. instead of just shifting @ulen.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31592 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SEV: Protect *all* of sev_mem_enc_register_region() with kvm->lockTake and hold kvm->lock for before checking sev_guest() insev_mem_enc_register_region(), as sev_guest() isn't stable unless kvm->lockis held (or KVM can guarantee KVM_SEV_INIT{2} has completed and can'trollack state). If KVM_SEV_INIT{2} fails, KVM can end up trying to add toa not-yet-initialized sev->regions_list, e.g. triggering a #GP Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 110 UID: 0 PID: 72717 Comm: syz.15.11462 Tainted: G U W O 6.16.0-smp-DEV #1 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:sev_mem_enc_register_region+0x3f0/0x4f0 ../include/linux/list.h:83 Code: <41> 80 3c 04 00 74 08 4c 89 ff e8 f1 c7 a2 00 49 39 ed 0f 84 c6 00 RSP: 0018:ffff88838647fbb8 EFLAGS: 00010256 RAX: dffffc0000000000 RBX: 1ffff92015cf1e0b RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff888367870000 RBP: ffffc900ae78f050 R08: ffffea000d9e0007 R09: 1ffffd4001b3c000 R10: dffffc0000000000 R11: fffff94001b3c001 R12: 0000000000000000 R13: ffff8982ab0bde00 R14: ffffc900ae78f058 R15: 0000000000000000 FS: 00007f34e9dc66c0(0000) GS:ffff89ee64d33000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe180adef98 CR3: 000000047210e000 CR4: 0000000000350ef0 Call Trace: kvm_arch_vm_ioctl+0xa72/0x1240 ../arch/x86/kvm/x86.c:7371 kvm_vm_ioctl+0x649/0x990 ../virt/kvm/kvm_main.c:5363 __se_sys_ioctl+0x101/0x170 ../fs/ioctl.c:51 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x6f/0x1f0 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f34e9f7e9a9 Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f34e9dc6038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f34ea1a6080 RCX: 00007f34e9f7e9a9 RDX: 0000200000000280 RSI: 000000008010aebb RDI: 0000000000000007 RBP: 00007f34ea000d69 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f34ea1a6080 R15: 00007ffce77197a8 with a syzlang reproducer that looks like: syz_kvm_add_vcpu$x86(0x0, &(0x7f0000000040)={0x0, &(0x7f0000000180)=ANY=[], 0x70}) (async) syz_kvm_add_vcpu$x86(0x0, &(0x7f0000000080)={0x0, &(0x7f0000000180)=ANY=[@ANYBLOB="..."], 0x4f}) (async) r0 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000200), 0x0, 0x0) r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0) r2 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000240), 0x0, 0x0) r3 = ioctl$KVM_CREATE_VM(r2, 0xae01, 0x0) ioctl$KVM_SET_CLOCK(r3, 0xc008aeba, &(0x7f0000000040)={0x1, 0x8, 0x0, 0x5625e9b0}) (async) ioctl$KVM_SET_PIT2(r3, 0x8010aebb, &(0x7f0000000280)={[...], 0x5}) (async) ioctl$KVM_SET_PIT2(r1, 0x4070aea0, 0x0) (async) r4 = ioctl$KVM_CREATE_VM(0xffffffffffffffff, 0xae01, 0x0) openat$kvm(0xffffffffffffff9c, 0x0, 0x0, 0x0) (async) ioctl$KVM_SET_USER_MEMORY_REGION(r4, 0x4020ae46, &(0x7f0000000400)={0x0, 0x0, 0x0, 0x2000, &(0x7f0000001000/0x2000)=nil}) (async) r5 = ioctl$KVM_CREATE_VCPU(r4, 0xae41, 0x2) close(r0) (async) openat$kvm(0xffffffffffffff9c, &(0x7f0000000000), 0x8000, 0x0) (async) ioctl$KVM_SET_GUEST_DEBUG(r5, 0x4048ae9b, &(0x7f0000000300)={0x4376ea830d46549b, 0x0, [0x46, 0x0, 0x0, 0x0, 0x0, 0x1000]}) (async) ioctl$KVM_RUN(r5, 0xae80, 0x0)Opportunistically use guard() to avoid having to define a new error labeland goto usage.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31596 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: handle invalid dinode in ocfs2_group_extend[BUG]kernel BUG at fs/ocfs2/resize.c:308!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTIRIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1feCall Trace: ... ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 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+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ...[CAUSE]ocfs2_group_extend() assumes that the global bitmap inode blockreturned from ocfs2_inode_lock() has already been validated andBUG_ONs when the signature is not a dinode. That assumption is toostrong for crafted filesystems because the JBD2-managed buffer pathcan bypass structural validation and return an invalid dinode to theresize ioctl.[FIX]Validate the dinode explicitly in ocfs2_group_extend(). If the globalbitmap buffer does not contain a valid dinode, report filesystemcorruption with ocfs2_error() and fail the resize operation instead ofcrashing the kernel.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31600 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: mm: Handle invalid large leaf mappings correctlyIt has been possible for a long time to mark ptes in the linear map asinvalid. This is done for secretmem, kfence, realm dma memory un/share,and others, by simply clearing the PTE_VALID bit. But until commita166563e7ec37 ("arm64: mm: support large block mapping whenrodata=full") large leaf mappings were never made invalid in this way.It turns out various parts of the code base are not equipped to handleinvalid large leaf mappings (in the way they are currently encoded) andI've observed a kernel panic while booting a realm guest on aBBML2_NOABORT system as a result:[ 15.432706] software IO TLB: Memory encryption is active and system is using DMA bounce buffers[ 15.476896] Unable to handle kernel paging request at virtual address ffff000019600000[ 15.513762] Mem abort info:[ 15.527245] ESR = 0x0000000096000046[ 15.548553] EC = 0x25: DABT (current EL), IL = 32 bits[ 15.572146] SET = 0, FnV = 0[ 15.592141] EA = 0, S1PTW = 0[ 15.612694] FSC = 0x06: level 2 translation fault[ 15.640644] Data abort info:[ 15.661983] ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000[ 15.694875] CM = 0, WnR = 1, TnD = 0, TagAccess = 0[ 15.723740] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 15.755776] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000081f3f000[ 15.800410] [ffff000019600000] pgd=0000000000000000, p4d=180000009ffff403, pud=180000009fffe403, pmd=00e8000199600704[ 15.855046] Internal error: Oops: 0000000096000046 [#1] SMP[ 15.886394] Modules linked in:[ 15.900029] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc4-dirty #4 PREEMPT[ 15.935258] Hardware name: linux,dummy-virt (DT)[ 15.955612] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)[ 15.986009] pc : __pi_memcpy_generic+0x128/0x22c[ 16.006163] lr : swiotlb_bounce+0xf4/0x158[ 16.024145] sp : ffff80008000b8f0[ 16.038896] x29: ffff80008000b8f0 x28: 0000000000000000 x27: 0000000000000000[ 16.069953] x26: ffffb3976d261ba8 x25: 0000000000000000 x24: ffff000019600000[ 16.100876] x23: 0000000000000001 x22: ffff0000043430d0 x21: 0000000000007ff0[ 16.131946] x20: 0000000084570010 x19: 0000000000000000 x18: ffff00001ffe3fcc[ 16.163073] x17: 0000000000000000 x16: 00000000003fffff x15: 646e612065766974[ 16.194131] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000[ 16.225059] x11: 0000000000000000 x10: 0000000000000010 x9 : 0000000000000018[ 16.256113] x8 : 0000000000000018 x7 : 0000000000000000 x6 : 0000000000000000[ 16.287203] x5 : ffff000019607ff0 x4 : ffff000004578000 x3 : ffff000019600000[ 16.318145] x2 : 0000000000007ff0 x1 : ffff000004570010 x0 : ffff000019600000[ 16.349071] Call trace:[ 16.360143] __pi_memcpy_generic+0x128/0x22c (P)[ 16.380310] swiotlb_tbl_map_single+0x154/0x2b4[ 16.400282] swiotlb_map+0x5c/0x228[ 16.415984] dma_map_phys+0x244/0x2b8[ 16.432199] dma_map_page_attrs+0x44/0x58[ 16.449782] virtqueue_map_page_attrs+0x38/0x44[ 16.469596] virtqueue_map_single_attrs+0xc0/0x130[ 16.490509] virtnet_rq_alloc.isra.0+0xa4/0x1fc[ 16.510355] try_fill_recv+0x2a4/0x584[ 16.526989] virtnet_open+0xd4/0x238[ 16.542775] __dev_open+0x110/0x24c[ 16.558280] __dev_change_flags+0x194/0x20c[ 16.576879] netif_change_flags+0x24/0x6c[ 16.594489] dev_change_flags+0x48/0x7c[ 16.611462] ip_auto_config+0x258/0x1114[ 16.628727] do_one_initcall+0x80/0x1c8[ 16.645590] kernel_init_freeable+0x208/0x2f0[ 16.664917] kernel_init+0x24/0x1e0[ 16.680295] ret_from_fork+0x10/0x20[ 16.696369] Code: 927cec03 cb0e0021 8b0e0042 a9411c26 (a900340c)[ 16.723106] ---[ end trace 0000000000000000 ]---[ 16.752866] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b[ 16.792556] Kernel Offset: 0x3396ea200000 from 0xffff8000800000---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31601 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vfio/xe: Reorganize the init to decouple migration from resetAttempting to issue reset on VF devices that don't support migrationleads to the following: BUG: unable to handle page fault for address: 00000000000011f8 #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: 2 UID: 0 PID: 7443 Comm: xe_sriov_flr Tainted: G S U 7.0.0-rc1-lgci-xe-xe-4588-cec43d5c2696af219-nodebug+ #1 PREEMPT(lazy) Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 RIP: 0010:xe_sriov_vfio_wait_flr_done+0xc/0x80 [xe] Code: ff c3 cc cc cc cc 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 54 53 <83> bf f8 11 00 00 02 75 61 41 89 f4 85 f6 74 52 48 8b 47 08 48 89 RSP: 0018:ffffc9000f7c39b8 EFLAGS: 00010202 RAX: ffffffffa04d8660 RBX: ffff88813e3e4000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000f7c39c8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff888101a48800 R13: ffff88813e3e4150 R14: ffff888130d0d008 R15: ffff88813e3e40d0 FS: 00007877d3d0d940(0000) GS:ffff88890b6d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000011f8 CR3: 000000015a762000 CR4: 0000000000f52ef0 PKRU: 55555554 Call Trace: xe_vfio_pci_reset_done+0x49/0x120 [xe_vfio_pci] pci_dev_restore+0x3b/0x80 pci_reset_function+0x109/0x140 reset_store+0x5c/0xb0 dev_attr_store+0x17/0x40 sysfs_kf_write+0x72/0x90 kernfs_fop_write_iter+0x161/0x1f0 vfs_write+0x261/0x440 ksys_write+0x69/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x259/0x26e0 do_syscall_64+0xcb/0x1500 ? __fput+0x1a2/0x2d0 ? fput_close_sync+0x3d/0xa0 ? __x64_sys_close+0x3e/0x90 ? x64_sys_call+0x1b7c/0x26e0 ? do_syscall_64+0x109/0x1500 ? __task_pid_nr_ns+0x68/0x100 ? __do_sys_getpid+0x1d/0x30 ? x64_sys_call+0x10b5/0x26e0 ? do_syscall_64+0x109/0x1500 ? putname+0x41/0x90 ? do_faccessat+0x1e8/0x300 ? __x64_sys_access+0x1c/0x30 ? x64_sys_call+0x1822/0x26e0 ? do_syscall_64+0x109/0x1500 ? tick_program_event+0x43/0xa0 ? hrtimer_interrupt+0x126/0x260 ? irqentry_exit+0xb2/0x710 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7877d5f1c5a4 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d a5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007fff48e5f908 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007877d5f1c5a4 RDX: 0000000000000001 RSI: 00007877d621b0c9 RDI: 0000000000000009 RBP: 0000000000000001 R08: 00005fb49113b010 R09: 0000000000000007 R10: 0000000000000000 R11: 0000000000000202 R12: 00007877d621b0c9 R13: 0000000000000009 R14: 00007fff48e5fac0 R15: 00007fff48e5fac0 This is caused by the fact that some of the xe_vfio_pci_core_devicemembers needed for handling reset are only initialized as part ofmigration init.Fix the problem by reorganizing the code to decouple VF init frommigration init.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31624 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: clamp report_size in s32ton() to avoid undefined shifts32ton() shifts by n-1 where n is the field's report_size, a value thatcomes directly from a HID device. The HID parser bounds report_sizeonly to <= 256, so a broken HID device can supply a report descriptorwith a wide field that triggers shift exponents up to 256 on a 32-bittype when an output report is built via hid_output_field() orhid_set_field().Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds inhid_report_raw_event") added the same n > 32 clamp to the functionsnto32(), but s32ton() was never given the same fix as I guess syzbothadn't figured out how to fuzz a device the same way.Fix this up by just clamping the max value of n, just like snto32()does.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31625 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: alps: fix NULL pointer dereference in alps_raw_event()Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_eventcallbacks missing them") attempted to fix up the HID drivers that hadmissed the previous fix that was done in 2ff5baa9b527 ("HID: appleir:Fix potential NULL dereference at raw event handle"), but the alpsdriver was missed.Fix this up by properly checking in the hid-alps driver that it had beenclaimed correctly before attempting to process the raw event.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31630 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: proc: size address buffers for %pISpc outputThe AF_RXRPC procfs helpers format local and remote socket addresses intofixed 50-byte stack buffers with "%pISpc".That is too small for the longest current-tree IPv6-with-port form theformatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses adotted-quad tail not only for v4mapped addresses, but also for ISATAPaddresses via ipv6_addr_is_isatap().As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535is possible with the current formatter. That is 50 visible characters, so51 bytes including the trailing NUL, which does not fit in the existingchar[50] buffers used by net/rxrpc/proc.c.Size the buffers from the formatter's maximum textual form and switch thecall sites to scnprintf().Changes since v1:- correct the changelog to cite the actual maximum current-tree case explicitly- frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31637 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: reject undecryptable rxkad response ticketsrxkad_decrypt_ticket() decrypts the RXKAD response ticket and thenparses the buffer as plaintext without checking whethercrypto_skcipher_decrypt() succeeded.A malformed RESPONSE can therefore use a non-block-aligned ticketlength, make the decrypt operation fail, and still drive the ticketparser with attacker-controlled bytes.Check the decrypt result and abort the connection with RXKADBADTICKETwhen ticket decryption fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31642 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix call removal to use RCU safe deletionFix rxrpc call removal from the rxnet->calls list to use list_del_rcu()rather than list_del_init() to prevent stuffing up reading/proc/net/rxrpc/calls from potentially getting into an infinite loop.This, however, means that list_empty() no longer works on an entry that'sbeen deleted from the list, making it harder to detect prior deletion. Fixthis by:Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls thatare unexpectedly still on the list. Limiting the number of steps meansthere's no need to call cond_resched() or to remove calls from the listhere, thereby eliminating the need for rxrpc_put_call() to check for that.rxrpc_put_call() can then be fixed to unconditionally delete the call fromthe list as it is the only place that the deletion occurs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31651 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mmc: vub300: fix NULL-deref on disconnectMake sure to deregister the controller before dropping the reference tothe driver data on disconnect to avoid NULL-pointer dereferences oruse-after-free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31660 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: allocate rx skb before consuming bytespn532_receive_buf() reports the number of accepted bytes to the serdevcore. The current code consumes bytes into recv_skb and may already handa complete frame to pn533_recv_frame() before allocating a fresh receivebuffer.If that alloc_skb() fails, the callback returns 0 even though it hasalready consumed bytes, and it leaves recv_skb as NULL for the nextreceive callback. That breaks the receive_buf() accounting contract andcan also lead to a NULL dereference on the next skb_put_u8().Allocate the receive skb lazily before consuming the next byte instead.If allocation fails, return the number of bytes already accepted.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31661 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmsmac: Fix dma_free_coherent() sizedma_alloc_consistent() may change the size to align it. The new size issaved in alloced.Change the free size to match the allocation size.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31664 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: clear trailing padding in build_polexpire()build_expire() clears the trailing padding bytes of structxfrm_user_expire after setting the hard field via memset_after(),but the analogous function build_polexpire() does not do this forstruct xfrm_user_polexpire.The padding bytes after the __u8 hard field are leftuninitialized from the heap allocation, and are then sent touserspace via netlink multicast to XFRMNLGRP_EXPIRE listeners,leaking kernel heap memory contents.Add the missing memset_after() call, matching build_expire().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31670 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: rfkill: prevent unlimited numbers of rfkill events from being createdUserspace can create an unlimited number of rfkill events if the systemis so configured, while not consuming them from the rfkill filedescriptor, causing a potential out of memory situation. Prevent thisfrom bounding the number of pending rfkill events at a "large" number(i.e. 1000) to prevent abuses like this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31674 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check()Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS.rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[].Validate addrnr during rule installation so malformed rules are rejectedbefore the match logic can use an out-of-range value.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31677 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - limit RX SG extraction by receive buffer budgetMake af_alg_get_rsgl() limit each RX scatterlist extraction to theremaining receive buffer budget.af_alg_get_rsgl() currently uses af_alg_readable() only as a gatebefore extracting data into the RX scatterlist. Limit each extractionto the remaining af_alg_rcvbuf(sk) budget so that receive-sideaccounting matches the amount of data attached to the request.If skcipher cannot obtain enough RX space for at least one chunk whilemore data remains to be processed, reject the recvmsg call instead ofrounding the request length down to zero.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31696 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix missing validation of ticket length in non-XDR key preparsingIn rxrpc_preparse(), there are two paths for parsing key payloads: theXDR path (for large payloads) and the non-XDR path (for payloads <= 28bytes). While the XDR path (rxrpc_preparse_xdr_rxkad()) correctlyvalidates the ticket length against AFSTOKEN_RK_TIX_MAX, the non-XDRpath fails to do so.This allows an unprivileged user to provide a very large ticket length.When this key is later read via rxrpc_read(), the totaltoken size (toksize) calculation results in a value that exceedsAFSTOKEN_LENGTH_MAX, triggering a WARN_ON().[ 2001.302904] WARNING: CPU: 2 PID: 2108 at net/rxrpc/key.c:778 rxrpc_read+0x109/0x5c0 [rxrpc]Fix this by adding a check in the non-XDR parsing path of rxrpc_preparse()to ensure the ticket length does not exceed AFSTOKEN_RK_TIX_MAX,bringing it into parity with the XDR parsing logic.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31732 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: Fix resource leaks on errors in gpiochip_add_data_with_key()Since commit aab5c6f20023 ("gpio: set device type for GPIO chips"),`gdev->dev.release` is unset. As a result, the reference count to`gdev->dev` isn't dropped on the error handling paths.Drop the reference on errors.Also reorder the instructions to make the error handling simpler.Now gpiochip_add_data_with_key() roughly looks like: >>> Some memory allocation. Go to ERR ZONE 1 on errors. >>> device_initialize(). gpiodev_release() takes over the responsibility for freeing the resources of `gdev->dev`. The subsequent error handling paths shouldn't go through ERR ZONE 1 again which leads to double free. >>> Some initialization mainly on `gdev`. >>> The rest of initialization. Go to ERR ZONE 2 on errors. >>> Chip registration success and exit. >>> ERR ZONE 2. gpio_device_put() and exit. >>> ERR ZONE 1.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31737 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ftgmac100: fix ring allocation unwind on open failureftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, andrx_scratch in stages. On intermediate failures it returned -ENOMEMdirectly, leaking resources allocated earlier in the function.Rework the failure path to use staged local unwind labels and freeallocated resources in reverse order before returning -ENOMEM. Thismatches common netdev allocation cleanup style.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31749 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: ni_atmio16d: Fix invalid clean-up after failed attachIf the driver's COMEDI "attach" handler function (`atmio16d_attach()`)returns an error, the COMEDI core will call the driver's "detach"handler function (`atmio16d_detach()`) to clean up. This calls`reset_atmio16d()` unconditionally, but depending on where the erroroccurred in the attach handler, the device may not have beensufficiently initialized to call `reset_atmio16d()`. It uses`dev->iobase` as the I/O port base address and `dev->private` as thepointer to the COMEDI device's private data structure. `dev->iobase`may still be set to its initial value of 0, which would result inundesired writes to low I/O port addresses. `dev->private` may still be`NULL`, which would result in null pointer dereferences.Fix `atmio16d_detach()` by checking that `dev->private` is valid(non-null) before calling `reset_atmio16d()`. This implies that`dev->iobase` was set correctly since that is set up before`dev->private`.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31751 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: dt2815: add hardware detection to prevent crashThe dt2815 driver crashes when attached to I/O ports without actualhardware present. This occurs because syzkaller or users can attachthe driver to arbitrary I/O addresses via COMEDI_DEVCONFIG ioctl.When no hardware exists at the specified port, inb() operations return0xff (floating bus), but outb() operations can trigger page faults dueto undefined behavior, especially under race conditions: BUG: unable to handle page fault for address: 000000007fffff90 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:dt2815_attach+0x6e0/0x1110Add hardware detection by reading the status register before attemptingany write operations. If the read returns 0xff, assume no hardware ispresent and fail the attach with -ENODEV. This prevents crashes fromoutb() operations on non-existent hardware.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31752 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bridge: br_nd_send: validate ND option lengthsbr_nd_send() walks ND options according to option-provided lengths.A malformed option can make the parser advance beyond the computedoption span or use a too-short source LLADDR option payload.Validate option lengths against the remaining NS option area beforeadvancing, and only read source LLADDR when the option is large enoughfor an Ethernet address.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31762 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: gyro: mpu3050: Fix irq resource leakThe interrupt handler is setup but only a few lines down ifiio_trigger_register() fails the function returns without properlyreleasing the handler.Add cleanup goto to resolve resource leak.Detected by Smatch:drivers/iio/gyro/mpu3050-core.c:1128 mpu3050_trigger_probe() warn:'irq' from request_threaded_irq() not released on lines: 1124.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31767 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/dsi: Don't do DSC horizontal timing adjustments in command modeStop adjusting the horizontal timing values based on thecompression ratio in command mode. Bspec seems to be tellingus to do this only in video mode, and this is also how theWindows driver does things.This should also fix a div-by-zero on some machines becausethe adjusted htotal ends up being so small that we end up withline_time_us==0 when trying to determine the vtotal value incommand mode.Note that this doesn't actually make the display on theHuawei Matebook E work, but at least the kernel no longerexplodes when the driver loads.(cherry picked from commit 0b475e91ecc2313207196c6d7fd5c53e1a878525)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31773 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SMP: derive legacy responder STK authentication from MITM stateThe legacy responder path in smp_random() currently labels the storedSTK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH.That reflects what the local service requested, not what the pairingflow actually achieved.For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clearand the resulting STK should remain unauthenticated even if the localside requested HIGH security. Use the established MITM state whenstoring the responder STK so the key metadata matches the pairing result.This also keeps the legacy path aligned with the Secure Connections code,which already treats JUST_WORKS/JUST_CFM as unauthenticated.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31777 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ctxfi: Check the error for index mappingThe ctxfi driver blindly assumed a proper value returned fromdaio_device_index(), but it's not always true. Add a proper errorcheck to deal with the error from the function.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31780 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculationThe variable valuesize is declared as u8 but accumulates the totallength of all SSIDs to scan. Each SSID contributes up to 33 bytes(IEEE80211_MAX_SSID_LEN + 1), and with WILC_MAX_NUM_PROBED_SSID (10)SSIDs the total can reach 330, which wraps around to 74 when storedin a u8.This causes kmalloc to allocate only 75 bytes while the subsequentmemcpy writes up to 331 bytes into the buffer, resulting in a 256-byteheap buffer overflow.Widen valuesize from u8 to u32 to accommodate the full range.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-31781 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/ioc32: stop speculation on the drm_compat_ioctl pathThe drm compat ioctl path takes a user controlled pointer, and thendereferences it into a table of function pointers, the signature methodof spectre problems. Fix this up by calling array_index_nospec() on theindex to the function pointer list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-33947 Severity: Moderate CVSS3 score: 5.5

Description: jq is a command-line JSON processor. In versions 1.8.1 and below, functions jv_setpath(), jv_getpath(), and delpaths_sorted() in jq's src/jv_aux.c use unbounded recursion whose depth is controlled by the length of a caller-supplied path array, with no depth limit enforced. An attacker can supply a JSON document containing a flat array of ~65,000 integers (~200 KB) that, when used as a path argument by a trusted jq filter, exhausts the C call stack and crashes the process with a segmentation fault (SIGSEGV). This bypass works because the existing MAX_PARSING_DEPTH (10,000) limit only protects the JSON parser, not runtime path operations where arrays can be programmatically constructed to arbitrary lengths. The impact is denial of service (unrecoverable crash) affecting any application or service that processes untrusted JSON input through jq's setpath, getpath, or delpaths builtins. This issue has been addressed in commit fb59f1491058d58bdc3e8dd28f1773d1ac690a1f.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
jq > 0-0 (version in image is 1.6-150000.3.12.1).

CVE-2026-34933 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. Prior to version 0.9-rc4, any unprivileged local user can crash avahi-daemon by sending a single D-Bus method call with conflicting publish flags. This issue has been patched in version 0.9-rc4.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.26.1).

CVE-2026-39314 Severity: Moderate CVSS3 score: 5.5

Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, an integer underflow vulnerability in _ppdCreateFromIPP() (cups/ppd-cache.c) allows any unprivileged local user to crash the cupsd root process by supplying a negative job-password-supported IPP attribute. The bounds check only caps the upper bound, so a negative value passes validation, is cast to size_t (wrapping to ~2^64), and is used as the length argument to memset() on a 33-byte stack buffer. This causes an immediate SIGSEGV in the cupsd root process. Combined with systemd's Restart=on-failure, an attacker can repeat the crash for sustained denial of service.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
cups-config > 0-0 (version in image is 2.2.7-150000.3.86.1).

CVE-2026-39316 Severity: Moderate CVSS3 score: 5.5

Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, a use-after-free vulnerability exists in the CUPS scheduler (cupsd) when temporary printers are automatically deleted. cupsdDeleteTemporaryPrinters() in scheduler/printers.c calls cupsdDeletePrinter() without first expiring subscriptions that reference the printer, leaving cupsd_subscription_t.dest as a dangling pointer to freed heap memory. The dangling pointer is subsequently dereferenced at multiple code sites, causing a crash (denial of service) of the cupsd daemon. With heap grooming, this can be leveraged for code execution.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
cups-config > 0-0 (version in image is 2.2.7-150000.3.86.1).

CVE-2026-39956 Severity: Moderate CVSS3 score: 5.5

Description: jq is a command-line JSON processor. In commits after 69785bf77f86e2ea1b4a20ca86775916889e91c9, the _strindices builtin in jq's src/builtin.c passes its arguments directly to jv_string_indexes() without verifying they are strings, and jv_string_indexes() in src/jv.c relies solely on assert() checks that are stripped in release builds compiled with -DNDEBUG. This allows an attacker to crash jq trivially with input like _strindices(0), and by crafting a numeric value whose IEEE-754 bit pattern maps to a chosen pointer, achieve a controlled pointer dereference and limited memory read/probe primitive. Any deployment that evaluates untrusted jq filters against a release build is vulnerable. This issue has been patched in commit fdf8ef0f0810e3d365cdd5160de43db46f57ed03.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
jq > 0-0 (version in image is 1.6-150000.3.12.1).

CVE-2026-40164 Severity: Moderate CVSS3 score: 5.5

Description: jq is a command-line JSON processor. Before commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784, jq used MurmurHash3 with a hardcoded, publicly visible seed (0x432A9843) for all JSON object hash table operations, which allowed an attacker to precompute key collisions offline. By supplying a crafted JSON object (~100 KB) where all keys hashed to the same bucket, hash table lookups degraded from O(1) to O(n), turning any jq expression into an O(n?) operation and causing significant CPU exhaustion. This affected common jq use cases such as CI/CD pipelines, web services, and data processing scripts, and was far more practical to exploit than existing heap overflow issues since it required only a small payload. This issue has been patched in commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
jq > 0-0 (version in image is 1.6-150000.3.12.1).

CVE-2026-40475 Severity: Moderate CVSS3 score: 5.5

Description: Unknown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-pyOpenSSL > 0-0 (version in image is 23.2.0-150400.3.16.1).

CVE-2026-41256 Severity: Moderate CVSS3 score: 5.5

Description: jq is a command-line JSON processor. In 1.8.1 and earlier, Top-level jq programs loaded from a file with -f are truncated at the first embedded NUL byte on current upstream HEAD. A crafted filter file such as . followed by \x00 and arbitrary suffix compiles and executes as only the prefix before the NUL. This leaves jq with a post-CVE-2026-33948 prefix/full-buffer mismatch on the compilation path even though the JSON parser path has already been fixed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
jq > 0-0 (version in image is 1.6-150000.3.12.1).

CVE-2026-43009 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix incorrect pruning due to atomic fetch precision trackingWhen backtrack_insn encounters a BPF_STX instruction with BPF_ATOMICand BPF_FETCH, the src register (or r0 for BPF_CMPXCHG) also acts asa destination, thus receiving the old value from the memory location.The current backtracking logic does not account for this. It treatsatomic fetch operations the same as regular stores where the srcregister is only an input. This leads the backtrack_insn to fail topropagate precision to the stack location, which is then not markedas precise!Later, the verifier's path pruning can incorrectly consider two statesequivalent when they differ in terms of stack state. Meaning, twobranches can be treated as equivalent and thus get pruned when theyshould not be seen as such.Fix it as follows: Extend the BPF_LDX handling in backtrack_insn toalso cover atomic fetch operations via is_atomic_fetch_insn() helper.When the fetch dst register is being tracked for precision, clear it,and propagate precision over to the stack slot. For non-stack memory,the precision walk stops at the atomic instruction, same as regularBPF_LDX. This covers all fetch variants.Before: 0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs=r2 stack= before 2: (b7) r2 = 0 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exitAfter: 0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs= stack=-8 before 2: (b7) r2 = 0 mark_precise: frame0: regs= stack=-8 before 1: (7b) *(u64 *)(r10 -8) = r1 mark_precise: frame0: regs=r1 stack= before 0: (b7) r1 = 8 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43014 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: properly unregister fixed rate clocksThe additional resources allocated with clk_register_fixed_rate() needto be released with clk_unregister_fixed_rate(), otherwise they are lost.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43015 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: fix clk handling on PCI glue driver removalplatform_device_unregister() may still want to use the registered clksduring runtime resume callback.Note that there is a commit d82d5303c4c5 ("net: macb: fix use after freeon rmmod") that addressed the similar problem of clk vs platform deviceunregistration but just moved the bug to another place.Save the pointers to clks into local variables for reuse after platformdevice is unregistered.BUG: KASAN: use-after-free in clk_prepare+0x5a/0x60Read of size 8 at addr ffff888104f85e00 by task modprobe/597CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x8d/0xba print_report+0x17f/0x496 kasan_report+0xd9/0x180 clk_prepare+0x5a/0x60 macb_runtime_resume+0x13d/0x410 [macb] pm_generic_runtime_resume+0x97/0xd0 __rpm_callback+0xc8/0x4d0 rpm_callback+0xf6/0x230 rpm_resume+0xeeb/0x1a70 __pm_runtime_resume+0xb4/0x170 bus_remove_device+0x2e3/0x4b0 device_del+0x5b3/0xdc0 platform_device_del+0x4e/0x280 platform_device_unregister+0x11/0x50 pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 519: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x8e/0x90 __clk_register+0x458/0x2890 clk_hw_register+0x1a/0x60 __clk_hw_register_fixed_rate+0x255/0x410 clk_register_fixed_rate+0x3c/0xa0 macb_probe+0x1d8/0x42e [macb_pci] local_pci_probe+0xd7/0x190 pci_device_probe+0x252/0x600 really_probe+0x255/0x7f0 __driver_probe_device+0x1ee/0x330 driver_probe_device+0x4c/0x1f0 __driver_attach+0x1df/0x4e0 bus_for_each_dev+0x15d/0x1f0 bus_add_driver+0x486/0x5e0 driver_register+0x23a/0x3d0 do_one_initcall+0xfd/0x4d0 do_init_module+0x18b/0x5a0 load_module+0x5663/0x7950 __do_sys_finit_module+0x101/0x180 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8Freed by task 597: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x180 __kmem_cache_free+0xbc/0x320 clk_unregister+0x6de/0x8d0 macb_remove+0x73/0xc0 [macb_pci] pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43020 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: validate LTK enc_size on loadLoad Long Term Keys stores the user-provided enc_size and later usesit to size fixed-size stack operations when replying to LE LTKrequests. An enc_size larger than the 16-byte key buffer can thereforeoverflow the reply stack buffer.Reject oversized enc_size values while validating the management LTKrecord so invalid keys never reach the stored key state.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43024 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: reject immediate NF_QUEUE verdictnft_queue is always used from userspace nftables to deliver the NF_QUEUEverdict. Immediately emitting an NF_QUEUE verdict is never used by theuserspace nft tools, so reject immediate NF_QUEUE verdicts.The arp family does not provide queue support, but such an immediateverdict is still reachable. Globally reject NF_QUEUE immediate verdictsto address this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43026 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absentctnetlink_alloc_expect() allocates expectations from a non-zeroingslab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is notpresent in the netlink message, saved_addr and saved_proto arenever initialized. Stale data from a previous slab occupant canthen be dumped to userspace by ctnetlink_exp_dump_expect(), whichchecks these fields to decide whether to emit CTA_EXPECT_NAT.The safe sibling nf_ct_expect_init(), used by the packet path,explicitly zeroes these fields.Zero saved_addr, saved_proto and dir in the else branch, guardedby IS_ENABLED(CONFIG_NF_NAT) since these fields only exist whenNAT is enabled.Confirmed by priming the expect slab with NAT-bearing expectations,freeing them, creating a new expectation without CTA_EXPECT_NAT,and observing that the ctnetlink dump emits a spuriousCTA_EXPECT_NAT containing stale data from the prior allocation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43028 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: ensure names are nul-terminatedReject names that lack a \0 character before feeding themto functions that expect c-strings.Fixes tag is the most recent commit that needs this change.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43030 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix regsafe() for pointers to packetIn case rold->reg->range == BEYOND_PKT_END && rcur->reg->range == Nregsafe() may return true which may lead to current state withvalid packet range not being explored. Fix the bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43032 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFC: pn533: bound the UART receive bufferpn532_receive_buf() appends every incoming byte to dev->recv_skb andonly resets the buffer after pn532_uart_rx_is_frame() recognizes acomplete frame. A continuous stream of bytes without a valid PN532 frameheader therefore keeps growing the skb until skb_put_u8() hits the taillimit.Drop the accumulated partial frame once the fixed receive buffer is fullso malformed UART traffic cannot grow the skb pastPN532_UART_SKB_BUFF_LEN.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43035 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to zero to prevent an info-leakWhen building netlink messages, tc_chain_fill_node() never initializesthe tcm_info field of struct tcmsg. Since the allocation is not zeroed,kernel heap memory is leaked to userspace through this 4-byte field.The fix simply zeroes tcm_info alongside the other fields that arealready initialized.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43036 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: use skb_header_pointer() for TCPv4 GSO frag_off checkSyzbot reported a KMSAN uninit-value warning in gso_features_check()called from netif_skb_features() [1].gso_features_check() reads iph->frag_off to decide whether to clearmangleid_features. Accessing the IPv4 header via ip_hdr()/inner_ip_hdr()can rely on skb header offsets that are not always safe for directdereference on packets injected from PF_PACKET paths.Use skb_header_pointer() for the TCPv4 frag_off check so the header readis robust whether data is already linear or needs copying.[1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43038 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this?This patch implements the first suggestion.I am not sure if ip6ip6_err() needs to be changed.A separate patch would be better anyway.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43040 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leakWhen processing Router Advertisements with user options the kernelbuilds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg structhas three padding fields that are never zeroed and can leak kernel dataThe fix is simple, just zeroes the padding fields.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43041 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak__radix_tree_create() allocates and links intermediate nodes into thetree one by one. If a subsequent allocation fails, the already-linkednodes remain in the tree with no corresponding leaf entry. These orphanedinternal nodes are never reclaimed because radix_tree_for_each_slot()only visits slots containing leaf values.The radix_tree API is deprecated in favor of xarray. As suggested byMatthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray insteadof fixing the radix_tree itself [1]. xarray properly handles cleanup ofinternal nodes - xa_destroy() frees all internal xarray nodes when theqrtr_node is released, preventing the leak.[1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43042 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mpls: add seqcount to protect the platform_label{,s} pairThe RCU-protected codepaths (mpls_forward, mpls_dump_routes) can havean inconsistent view of platform_labels vs platform_label in case of aconcurrent resize (resize_platform_label_table, underplatform_mutex). This can lead to OOB accesses.This patch adds a seqcount, so that we get a consistent snapshot.Note that mpls_label_ok is also susceptible to this, so the checkagainst RTA_DST in rtm_to_route_config, done outside platform_mutex,is not sufficient. This value gets passed to mpls_label_ok once morein both mpls_route_add and mpls_route_del, so there is no issue, butthat additional check must not be removed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43043 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af-alg - fix NULL pointer dereference in scatterwalkThe AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL)when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGLexactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequentsendmsg() allocates a new SGL and chains it, but fails to clear the endmarker on the previous SGL's last data entry.This causes the crypto scatterwalk to hit a premature end, returning NULLon sg_next() and leading to a kernel panic during dereference.Fix this by explicitly unmarking the end of the previous SGL whenperforming sg_chain() in af_alg_alloc_tsgl().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43046 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reject root items with drop_progress and zero drop_level[BUG]When recovering relocation at mount time, merge_reloc_root() andbtrfs_drop_snapshot() both use BUG_ON(level == 0) to guard againstan impossible state: a non-zero drop_progress combined with a zerodrop_level in a root_item, which can be triggered:------------[ cut here ]------------kernel BUG at fs/btrfs/relocation.c:1545!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary)Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000Call Trace: merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861 btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195 btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130 open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640 btrfs_fill_super fs/btrfs/super.c:987 [inline] btrfs_get_tree_super fs/btrfs/super.c:1951 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline] btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ...RIP: 0033:0x7f969c9a8fdeCode: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f---[ end trace 0000000000000000 ]---The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamicmetadata fuzzing tool that corrupts btrfs metadata at runtime.[CAUSE]A non-zero drop_progress.objectid means an interruptedbtrfs_drop_snapshot() left a resume point on disk, and in that casedrop_level must be greater than 0 because the checkpoint is onlysaved at internal node levels.Although this invariant is enforced when the kernel writes the rootitem, it is not validated when the root item is read back from disk.That allows on-disk corruption to provide an invalid state withdrop_progress.objectid != 0 and drop_level == 0.When relocation recovery later processes such a root item,merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). Thesame invalid metadata can also trigger the corresponding BUG_ON() inbtrfs_drop_snapshot().[FIX]Fix this by validating the root_item invariant in tree-checker whenreading root items from disk: if drop_progress.objectid is non-zero,drop_level must also be non-zero. Reject such malformed metadata with-EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot()and triggers the BUG_ON.After the fix, the same corruption is correctly rejected by tree-checkerand the BUG_ON is no longer triggered.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43047 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: multitouch: Check to ensure report responses match the requestIt is possible for a malicious (or clumsy) device to respond to aspecific report's feature request using a completely different reportID. This can cause confusion in the HID core resulting in nastyside-effects such as OOB writes.Add a check to ensure that the report ID in the response, matches theone that was requested. If it doesn't, omit reporting the raw event andreturn early.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43048 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: Mitigate potential OOB by removing bogus memset()The memset() in hid_report_raw_event() has the good intention ofclearing out bogus data by zeroing the area from the end of the incomingdata string to the assumed end of the buffer. However, as we havepreviously seen, doing so can easily result in OOB reads and writes inthe subsequent thread of execution.The current suggestion from one of the HID maintainers is to remove thememset() and simply return if the incoming event buffer size is notlarge enough to fill the associated report.Suggested-by Benjamin Tissoires [bentiss: changed the return value]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43049 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failurePresently, if the force feedback initialisation fails when probing theLogitech G920 Driving Force Racing Wheel for Xbox One, an error numberwill be returned and propagated before the userspace infrastructure(sysfs and /dev/input) has been torn down. If userspace ignores theerrors and continues to use its references to these dangling entities, aUAF will promptly follow.We have 2 options; continue to return the error, but ensure that all ofthe infrastructure is torn down accordingly or continue to treat thiscondition as a warning by emitting the message but returning success.It is thought that the original author's intention was to emit thewarning but keep the device functional, less the force feedback feature,so let's go with that.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43051 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irqThe wacom_intuos_bt_irq() function processes Bluetooth HID reportswithout sufficient bounds checking. A maliciously crafted short reportcan trigger an out-of-bounds read when copying data into the wacomstructure.Specifically, report 0x03 requires at least 22 bytes to safely readthe processed data and battery status, while report 0x04 (whichfalls through to 0x03) requires 32 bytes.Add explicit length checks for these report IDs and log a warning ifa short report is received.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43053 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: close crash window in attr dabtree inactivationWhen inactivating an inode with node-format extended attributes,xfs_attr3_node_inactive() invalidates all child leaf/node blocks viaxfs_trans_binval(), but intentionally does not remove the correspondingentries from their parent node blocks. The implicit assumption is thatxfs_attr_inactive() will truncate the entire attr fork to zero extentsafterwards, so log recovery will never reach the root node and followthose stale pointers.However, if a log shutdown occurs after the leaf/node block cancellationscommit but before the attr bmap truncation commits, this assumptionbreaks. Recovery replays the attr bmap intact (the inode still hasattr fork extents), but suppresses replay of all cancelled leaf/nodeblocks, maybe leaving them as stale data on disk. On the next mount,xlog_recover_process_iunlinks() retries inactivation and attempts toread the root node via the attr bmap. If the root node was not replayed,reading the unreplayed root block triggers a metadata verificationfailure immediately; if it was replayed, following its child pointersto unreplayed child blocks triggers the same failure: XFS (pmem0): Metadata corruption detected at xfs_da3_node_read_verify+0x53/0x220, xfs_da3_node block 0x78 XFS (pmem0): Unmount and run xfs_repair XFS (pmem0): First 128 bytes of corrupted metadata buffer: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ XFS (pmem0): metadata I/O error in "xfs_da_read_buf+0x104/0x190" at daddr 0x78 len 8 error 117Fix this in two places:In xfs_attr3_node_inactive(), after calling xfs_trans_binval() on achild block, immediately remove the entry that references it from theparent node in the same transaction. This eliminates the window wherethe parent holds a pointer to a cancelled block. Once all children areremoved, the now-empty root node is converted to a leaf block within thesame transaction. This node-to-leaf conversion is necessary for crashsafety. If the system shutdown after the empty node is written to thelog but before the second-phase bmap truncation commits, log recoverywill attempt to verify the root block on disk. xfs_da3_node_verify()does not permit a node block with count == 0; such a block will failverification and trigger a metadata corruption shutdown. on the otherhand, leaf blocks are allowed to have this transient state.In xfs_attr_inactive(), split the attr fork truncation into two explicitphases. First, truncate all extents beyond the root block (the childextents whose parent references have already been removed above).Second, invalidate the root block and truncate the attr bmap to zero ina single transaction. The two operations in the second phase must beatomic: as long as the attr bmap has any non-zero length, recovery canfollow it to the root block, so the root block invalidation must committogether with the bmap-to-zero truncation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43054 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Drain commands in target_reset handlertcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESSwithout draining any in-flight commands. The SCSI EH documentation(scsi_eh.rst) requires that when a reset handler returns SUCCESS the driverhas made lower layers "forget about timed out scmds" and is ready for newcommands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug,mpi3mr) enforces this by draining or completing outstanding commands beforereturning SUCCESS.Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flightscsi_cmnd structures for recovery commands (e.g. TUR) while the target corestill has async completion work queued for the old se_cmd. The memset inqueuecommand zeroes se_lun and lun_ref_active, causingtransport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUNreference prevents transport_clear_lun_ref() from completing, hangingconfigfs LUN unlink forever in D-state: INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transport_clear_lun_ref+0x78/0x90 [target_core_mod] core_tpg_remove_lun+0x28/0xb0 [target_core_mod] target_fabric_port_unlink+0x50/0x60 [target_core_mod] configfs_unlink+0x156/0x1f0 [configfs] vfs_unlink+0x109/0x290 do_unlinkat+0x1d5/0x2d0Fix this by making tcm_loop_target_reset() actually drain commands: 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that the target core knows about (those not yet CMD_T_COMPLETE). 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and flush_work() on each se_cmd - this drains any deferred completion work for commands that already had CMD_T_COMPLETE set before the TMR (which the TMR skips via __target_check_io_state()). This is the same pattern used by mpi3mr, scsi_debug, and libsas to drain outstanding commands during reset.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43056 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: fix use-after-free in add_adev() error pathIf auxiliary_device_add() fails, add_adev() jumps to add_fail and callsauxiliary_device_uninit(adev).The auxiliary device has its release callback set to adev_release(),which frees the containing struct mana_adev. Since adev is embedded instruct mana_adev, the subsequent fall-through to init_fail and accessto adev->id may result in a use-after-free.Fix this by saving the allocated auxiliary device id in a localvariable before calling auxiliary_device_add(), and use that saved idin the cleanup path after auxiliary_device_uninit().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43060 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: drop pending enqueued packets on removalPackets sitting in nfqueue might hold a reference to:- templates that specify the conntrack zone, because a percpu area is used and module removal is possible.- conntrack timeout policies and helper, where object removal leave a stale reference.Since these objects can just go away, drop enqueued packets to avoidstale reference to them.If there is a need for finer grain removal, this logic can be revisitedto make selective packet drop upon dependencies.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43062 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp()l2cap_ecred_reconf_rsp() casts the incoming data to structl2cap_ecred_conn_rsp (the ECRED *connection* response, 8 bytes withresult at offset 6) instead of struct l2cap_ecred_reconf_rsp (2 byteswith result at offset 0).This causes two problems: - The sizeof(*rsp) length check requires 8 bytes instead of the correct 2, so valid L2CAP_ECRED_RECONF_RSP packets are rejected with -EPROTO. - rsp->result reads from offset 6 instead of offset 0, returning wrong data when the packet is large enough to pass the check.Fix by using the correct type. Also pass the already byte-swappedresult variable to BT_DBG instead of the raw __le16 field.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43064 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Fix not releasing workqueue on .release()The workqueue associated with an DSA/IAA device is not released whenthe object is freed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_ll: Fix firmware leak on error pathSmatch reports:drivers/bluetooth/hci_ll.c:587 download_firmware() warn:'fw' from request_firmware() not released on lines: 544.In download_firmware(), if request_firmware() succeeds but the returnedfirmware content is invalid (no data or zero size), the function returnswithout releasing the firmware, resulting in a resource leak.Fix this by calling release_firmware() before returning whenrequest_firmware() succeeded but the firmware content is invalid.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43078 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsglWhen page reassignment was added to af_alg_pull_tsgl the originalloop wasn't updated so it may try to reassign one more page thannecessary.Add the check to the reassignment so that this does not happen.Also update the comment which still refers to the obsolete offsetargument.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43079 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel/uncore: Skip discovery table for offline diesThis warning can be triggered if NUMA is disabled and the systemboots with fewer CPUs than the number of CPUs in die 0.WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore]Currently, the discovery table continues to be parsed even if all CPUsin the associated die are offline. This can lead to an array overflowat "pmu->boxes[die] = box" in uncore_pci_pmu_register(), which maytrigger the warning above or cause other issues.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43080 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: Drop large packets with UDP encapsyzbot reported a WARN on my patch series [1]. The actual issue is anoverflow of 16-bit UDP length field, and it exists in the upstream code.My series added a debug WARN with an overflow check that exposed theissue, that's why syzbot tripped on my patches, rather than on upstreamcode.syzbot's repro:r0 = socket$pppl2tp(0x18, 0x1, 0x1)r1 = socket$inet6_udp(0xa, 0x2, 0x0)connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c)connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\x00', '\xff\xff', @empty}}}}, 0x32)writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)="ee", 0x34000}], 0x1)It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDPencapsulation, and l2tp_xmit_core doesn't check for overflows when itassigns the UDP length field. The value gets trimmed to 16 bites.Add an overflow check that drops oversized packets and avoids sendingpackets with trimmed UDP length to the wire.syzbot's stack trace (with my patch applied):len >= 65536uWARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957Modules linked in:CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline]RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline]RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4fRSP: 0018:ffffc90003d67878 EFLAGS: 00010293RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffffRBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0Call Trace: pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x503/0x550 net/socket.c:1195 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1 vfs_writev+0x33c/0x990 fs/read_write.c:1059 do_writev+0x154/0x2e0 fs/read_write.c:1105 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f636479c629Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43085 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminatorWhen batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send()appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload vianlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put()helper only zeroes alignment padding after the payload, not the payloaditself, so four bytes of stale kernel heap data are leaked to userspacein the NLMSG_DONE message body.Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializesthe nfgenmsg payload via nfnl_fill_hdr(), consistent with how__build_packet_message() already constructs NFULNL_MSG_PACKET headers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43089 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm_user: fix info leak in build_mapping()struct xfrm_usersa_id has a one-byte padding hole after the protofield, which ends up never getting set to zero before copying out touserspace. Fix that up by zeroing out the whole structure beforesetting individual variables.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43091 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Wait for RCU readers during policy netns exitxfrm_policy_fini() frees the policy_bydst hash tables after flushing thepolicy work items and deleting all policies, but it does not wait forconcurrent RCU readers to leave their read-side critical sections first.The policy_bydst tables are published via rcu_assign_pointer() and arelooked up through rcu_dereference_check(), so netns teardown must alsowait for an RCU grace period before freeing the table memory.Fix this by adding synchronize_rcu() before freeing the policy hash tables.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43093 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: tighten UMEM headroom validation to account for tailroom and min frameThe current headroom validation in xdp_umem_reg() could leave us withinsufficient space dedicated to even receive minimum-sized ethernetframe. Furthermore if multi-buffer would come to play thenskb_shared_info stored at the end of XSK frame would be corrupted.HW typically works with 128-aligned sizes so let us provide this valueas bare minimum.Multi-buffer setting is known later in the configuration process sobesides accounting for 128 bytes, let us also take care of tailroom spaceupfront.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43098 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: s3fwrn5: allocate rx skb before consuming bytess3fwrn82_uart_read() reports the number of accepted bytes to the serdevcore. The current code consumes bytes into recv_skb and may alreadydeliver a complete frame before allocating a fresh receive buffer.If that alloc_skb() fails, the callback returns 0 even though it hasalready consumed bytes, and it leaves recv_skb as NULL for the nextreceive callback. That breaks the receive_buf() accounting contract andcan also lead to a NULL dereference on the next skb_put_u8().Allocate the receive skb lazily before consuming the next byte instead.If allocation fails, return the number of bytes already accepted.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43099 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: icmp: fix null-ptr-deref in icmp_build_probe()ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when theIPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passingthis error pointer to dev_hold() will cause a kernel crash withnull-ptr-deref.Instead, silently discard the request. RFC 8335 does not appear todefine a specific response for the case where an IPv6 interfaceidentifier is syntactically valid but the implementation cannot performthe lookup at runtime, and silently dropping the request may safer thanmisreporting "No Such Interface".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43103 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: lapbether: handle NETDEV_PRE_TYPE_CHANGElapbeth_data_transmit() expects the underlying device typeto be ARPHRD_ETHER.Returning NOTIFY_BAD from lapbeth_device_event() makes surebonding driver can not break this expectation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43104 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: Fix a memory leak in hang state error pathWhen vc4_save_hang_state() encounters an early return condition, itreturns without freeing the previously allocated `kernel_state`,leaking memory.Add the missing kfree() calls by consolidating the early return pathsinto a single place.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43105 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: Fix memory leak of BO array in hang stateThe hang state's BO array is allocated separately with kzalloc() invc4_save_hang_state() but never freed in vc4_free_hang_state(). Add themissing kfree() for the BO array before freeing the hang state struct.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43107 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: account XFRMA_IF_ID in aevent size calculationxfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), thenbuild_aevent() appends attributes including XFRMA_IF_ID when x->if_id isset.xfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For stateswith if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err < 0)in xfrm_get_ae(), turning a malformed netlink interaction into a kernelpanic.Account XFRMA_IF_ID in the size calculation unconditionally and replacethe BUG_ON with normal error unwinding.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43112 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepathWhen cifs_sanitize_prepath is called with an empty string or a stringcontaining only delimiters (e.g., "/"), the current logic attempts tocheck *(cursor2 - 1) before cursor2 has advanced. This results in anout-of-bounds read.This patch adds an early exit check after stripping prependeddelimiters. If no path content remains, the function returns NULL.The bug was identified via manual audit and verified using astandalone test case compiled with AddressSanitizer, whichtriggered a SEGV on affected inputs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43113 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wl1251: validate packet IDs before indexing tx_frameswl1251_tx_packet_cb() uses the firmware completion ID directly to indexthe fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from thecompletion block, and the callback does not currently verify that itfits the array before dereferencing it.Reject completion IDs that fall outside wl->tx_frames[] and keep theexisting NULL check in the same guard. This keeps the fix local to thetrust boundary and avoids touching the rest of the completion flow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43114 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiryNew test case fails unexpectedly when avx2 matching functions are used.The test first loads a ranomly generated pipapo setwith 'ipv4 . port' key, i.e. nft -f foo.This works. Then, it reloads the set after a flush:(echo flush set t s; cat foo) | nft -f -This is expected to work, because its the same set after all and it wasalready loaded once.But with avx2, this fails: nft reports a clashing element.The reported clash is of following form: We successfully re-inserted a . b c . dThen we try to insert a . davx2 finds the already existing a . d, which (due to 'flush set') is markedas invalid in the new generation. It skips the element and moves to next.Due to incorrect masking, the skip-step finds the next matchingelement *only considering the first field*,i.e. we return the already reinserted "a . b", even though thelast field is different and the entry should not have been matched.No such error is reported for the generic c implementation (no avx2) or whenthe last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback.Bisection points to7711f4bb4b36 ("netfilter: nft_set_pipapo: fix range overlap detection")but that fix merely uncovers this bug.Before this commit, the wrong element is returned, but erronouslyreported as a full, identical duplicate.The root-cause is too early return in the avx2 match functions.When we process the last field, we should continue to process datauntil the entire input size has been consumed to make sure no stalebits remain in the map.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43115 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:srcu: Use irq_work to start GP in tiny SRCUTiny SRCU's srcu_gp_start_if_needed() directly calls schedule_work(),which acquires the workqueue pool->lock.This causes a lockdep splat when call_srcu() is called with a schedulerlock held, due to: call_srcu() [holding pi_lock] srcu_gp_start_if_needed() schedule_work() -> pool->lock workqueue_init() / create_worker() [holding pool->lock] wake_up_process() -> try_to_wake_up() -> pi_lockAlso add irq_work_sync() to cleanup_srcu_struct() to prevent ause-after-free if a queued irq_work fires after cleanup begins.Tested with rcutorture SRCU-T and no lockdep warnings.[ Thanks to Boqun for similar fix in patch "rcu: Use an intermediate irq_workto start process_srcu()" ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43116 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: ensure safe access to master conntrackHolding reference on the expectation is not sufficient, the masterconntrack object can just go away, making exp->master invalid.To access exp->master safely:- Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away.- Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths.This patch goes for extending the nf_conntrack_expect_lock sectionto address this issue for simplicity, in the cases that are describedbelow this is just slightly extending the lock section.The add expectation command already holds a reference to the masterconntrack from ctnetlink_create_expect().However, the delete expectation command needs to grab the spinlockbefore looking up for the expectation. Expand the existing spinlocksection to address this to cover the expectation lookup. Note that,the nf_ct_expect_iterate_net() calls already grabs the spinlock whileiterating over the expectation table, which is correct.The get expectation command needs to grab the spinlock to ensure masterconntrack does not go away. This also expands the existing spinlocksection to cover the expectation lookup too. I needed to move thenetlink skb allocation out of the spinlock to keep it GFP_KERNEL.For the expectation events, the IPEXP_DESTROY event is already deliveredunder the spinlock, just move the delivery of IPEXP_NEW under thespinlock too because the master conntrack event cache is reached throughexp->master.While at it, add lockdep notations to help identify what codepaths needto grab the spinlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43117 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file()If overlay is used on top of btrfs, dentry->d_sb translates to overlay'ssuper block and fsid assignment will lead to a crash.Use file_inode(file)->i_sb to always get btrfs_sb.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43123 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: check return value of con2fb_acquire_newinfo()If fbcon_open() fails when called from con2fb_acquire_newinfo() theninfo->fbcon_par pointer remains NULL which is later dereferenced.Add check for return value of the function con2fb_acquire_newinfo() toavoid it.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43124 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pstore: ram_core: fix incorrect success return when vmap() failsIn persistent_ram_vmap(), vmap() may return NULL on failure.If offset is non-zero, adding offset_in_page(start) causes the functionto return a non-NULL pointer even though the mapping failed.persistent_ram_buffer_map() therefore incorrectly returns success.Subsequent access to prz->buffer may dereference an invalid addressand cause crashes.Add proper NULL checking for vmap() failures.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43125 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dlm: validate length in dlm_search_rsb_treeThe len parameter in dlm_dump_rsb_name() is not validated and comesfrom network messages. When it exceeds DLM_RESNAME_MAXLEN, it cancause out-of-bounds write in dlm_search_rsb_tree().Add length validation to prevent potential buffer overflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43128 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/umem: Fix double dma_buf_unpin in failure pathIn ib_umem_dmabuf_get_pinned_with_dma_device(), the call toib_umem_dmabuf_map_pages() can fail. If this occurs, the dmabufis immediately unpinned but the umem_dmabuf->pinned flag is stillset. Then, when ib_umem_release() is called, it callsib_umem_dmabuf_revoke() which will call dma_buf_unpin() again.Fix this by removing the immediate unpin upon failure and just letthe ib_umem_release/revoke path handle it. This also ensures theproper unmap-unpin unwind ordering if the dmabuf_map_pages callhappened to fail due to dma_resv_wait_timeout (and therefore hasa non-NULL umem_dmabuf->sgt).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43132 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm-verity: correctly handle dm_bufio_client_create() failureIf either of the calls to dm_bufio_client_create() in verity_fec_ctr()fails, then dm_bufio_client_destroy() is later called with an ERR_PTR()argument. That causes a crash. Fix this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43133 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulationCommit cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmloadof guest state") made KVM always use vmcb01 for the fields controlled byVMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation codeto always use vmcb01.As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is notintercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01instead of the current VMCB.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43134 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQThis adds a check for encryption key size upon receivingL2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C whichexpects L2CAP_CR_LE_BAD_KEY_SIZE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43135 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: cx23885: Add missing unmap in snd_cx23885_hw_params()In error path, add cx23885_alsa_dma_unmap() to release theresource acquired by cx23885_alsa_dma_map().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43136 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: logitech-hidpp: Check maxfield in hidpp_get_report_length()Do not crash when a report has no fields.Fake USB gadgets can send their own HID report descriptors and can define reportstructures without valid fields. This can be used to crash the kernel over USB.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43139 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm6: fix uninitialized saddr in xfrm6_get_saddr()xfrm6_get_saddr() does not check the return value ofipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitablesource address (returns -EADDRNOTAVAIL), saddr->in6 is leftuninitialized, but xfrm6_get_saddr() still returns 0 (success).This causes the caller xfrm_tmpl_resolve_one() to use the uninitializedaddress in xfrm_state_find(), triggering KMSAN warning:=====================================================BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940 xfrm_state_find+0x2424/0xa940 xfrm_resolve_and_create_bundle+0x906/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 xfrm_lookup_route+0x63/0x2b0 ip_route_output_flow+0x1ce/0x270 udp_sendmsg+0x2ce1/0x3400 inet_sendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64_sys_sendto+0x130/0x200 x64_sys_call+0x332b/0x3e70 do_syscall_64+0xd3/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7fLocal variable tmp.i.i created at: xfrm_resolve_and_create_bundle+0x3e3/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770=====================================================Fix by checking the return value of ipv6_dev_get_saddr() and propagatingthe error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43143 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mfd: core: Add locking around 'mfd_of_node_list'Manipulating a list in the kernel isn't safe without some sort ofmutual exclusion. Add a mutex any time we access / modify'mfd_of_node_list' to prevent possible crashes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43148 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/smp: Add check for kcalloc() failure in parse_thread_groups()As kcalloc() may fail, check its return value to avoid a NULL pointerdereference when passing it to of_property_read_u32_array().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43149 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean()The priv->rx_buffer and priv->tx_buffer are alloc'd together ascontiguous buffers in uhdlc_init() but freed as two buffers inuhdlc_memclean().Change the cleanup to only call dma_free_coherent() once on the wholebuffer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43152 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: hid-pl: handle probe errorsErrors in init must be reported back or we'llfollow a NULL pointer the first time FF is used.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43156 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: pegasus: enable basic endpoint checkingpegasus_probe() fills URBs with hardcoded endpoint pipes withoutverifying the endpoint descriptors: - usb_rcvbulkpipe(dev, 1) for RX data - usb_sndbulkpipe(dev, 2) for TX data - usb_rcvintpipe(dev, 3) for status interruptsA malformed USB device can present these endpoints with transfer typesthat differ from what the driver assumes.Add a pegasus_usb_ep enum for endpoint numbers, replacing magicconstants throughout. Add usb_check_bulk_endpoints() andusb_check_int_endpoints() calls before any resource allocation toverify endpoint types before use, rejecting devices with mismatcheddescriptors at probe time, and avoid triggering assertion.Similar fix to- commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking")- commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43157 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: CGX: fix bitmap leaksThe RX/TX flow-control bitmaps (rx_fc_pfvf_bmap and tx_fc_pfvf_bmap)are allocated by cgx_lmac_init() but never freed in cgx_lmac_exit().Unbinding and rebinding the driver therefore triggers kmemleak: unreferenced object (size 16): backtrace: rvu_alloc_bitmap cgx_probeFree both bitmaps during teardown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43161 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Skip dev-iotlb flush for inaccessible PCIe device without scalable modePCIe endpoints with ATS enabled and passed through to userspace(e.g., QEMU, DPDK) can hard-lock the host when their link drops,either by surprise removal or by a link fault.Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidationrequest when device is disconnected") adds pci_dev_is_disconnected()to devtlb_invalidation_with_pasid() so ATS invalidation is skippedonly when the device is being safely removed, but it applies onlywhen Intel IOMMU scalable mode is enabled.With scalable mode disabled or unsupported, a system hard-lockoccurs when a PCIe endpoint's link drops because the Intel IOMMUwaits indefinitely for an ATS invalidation that cannot complete.Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 domain_context_clear_one_cb pci_for_each_dma_alias device_block_translation blocking_domain_attach_dev iommu_deinit_device __iommu_group_remove_device iommu_release_device iommu_bus_notifier blocking_notifier_call_chain bus_notify device_del pci_remove_bus_device pci_stop_and_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_istCommit 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release")adds intel_pasid_teardown_sm_context() to intel_iommu_release_device(),which calls qi_flush_dev_iotlb() and can also hard-lock the systemwhen a PCIe endpoint's link drops.Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 intel_context_flush_no_pasid device_pasid_table_teardown pci_pasid_table_teardown pci_for_each_dma_alias intel_pasid_teardown_sm_context intel_iommu_release_device iommu_deinit_device __iommu_group_remove_device iommu_release_device iommu_bus_notifier blocking_notifier_call_chain bus_notify device_del pci_remove_bus_device pci_stop_and_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_istSometimes the endpoint loses connection without a link-down event(e.g., due to a link fault); killing the process (virsh destroy)then hard-locks the host.Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 domain_context_clear_one_cb pci_for_each_dma_alias device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fputpci_dev_is_disconnected() only covers safe-removal paths;pci_device_is_present() tests accessibility by readingvendor/device IDs and internally calls pci_dev_is_disconnected().On a ConnectX-5 (8 GT/s, x2) this costs ~70 ?s.Since __context_flush_dev_iotlb() is only called on{attach,release}_dev paths (not hot), add pci_device_is_present()there to skip inaccessible devices and avoid the hard-lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43162 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: tegra-video: Fix memory leak in __tegra_channel_try_format()The state object allocated by __v4l2_subdev_state_alloc() must be freedwith __v4l2_subdev_state_free() when it is no longer needed.In __tegra_channel_try_format(), two error paths return directly afterv4l2_subdev_call() fails, without freeing the allocated 'sd_state'object. This violates the requirement and causes a memory leak.Fix this by introducing a cleanup label and using goto statements in theerror paths to ensure that __v4l2_subdev_state_free() is always calledbefore the function returns.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43163 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/bitmap: fix GPF in write_page caused by resize raceA General Protection Fault occurs in write_page() during array resize:RIP: 0010:write_page+0x22b/0x3c0 [md_mod]This is a use-after-free race between bitmap_daemon_work() and__bitmap_resize(). The daemon iterates over `bitmap->storage.filemap`without locking, while the resize path frees that storage viamd_bitmap_file_unmap(). `quiesce()` does not stop the md thread,allowing concurrent access to freed pages.Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43167 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: always flush state and policy upon NETDEV_UNREGISTER eventsyzbot is reporting that "struct xfrm_state" refcount is leaking. unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 2 ref_tracker: netdev@ffff888052f24618 has 1/1 users at __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline] netdev_tracker_alloc include/linux/netdevice.h:4412 [inline] xfrm_dev_state_add+0x3a5/0x1080 net/xfrm/xfrm_device.c:316 xfrm_state_construct net/xfrm/xfrm_user.c:986 [inline] xfrm_add_sa+0x34ff/0x5fa0 net/xfrm/xfrm_user.c:1022 xfrm_user_rcv_msg+0x58e/0xc00 net/xfrm/xfrm_user.c:3507 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2550 xfrm_netlink_rcv+0x71/0x90 net/xfrm/xfrm_user.c:3529 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa5d/0xc30 net/socket.c:2592 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2646 __sys_sendmsg+0x16d/0x220 net/socket.c:2678 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/0x7fThis is because commit d77e38e612a0 ("xfrm: Add an IPsec hardwareoffloading API") implemented xfrm_dev_unregister() as no-op despitexfrm_dev_state_add() from xfrm_state_construct() acquires a referenceto "struct net_device".I guess that that commit expected that NETDEV_DOWN event is fired beforeNETDEV_UNREGISTER event fires, and also assumed that xfrm_dev_state_add()is called only if (dev->features & NETIF_F_HW_ESP) != 0.Sabrina Dubroca identified steps to reproduce the same symptoms as below. echo 0 > /sys/bus/netdevsim/new_device dev=$(ls -1 /sys/bus/netdevsim/devices/netdevsim0/net/) ip xfrm state add src 192.168.13.1 dst 192.168.13.2 proto esp \ spi 0x1000 mode tunnel aead 'rfc4106(gcm(aes))' $key 128 \ offload crypto dev $dev dir out ethtool -K $dev esp-hw-offload off echo 0 > /sys/bus/netdevsim/del_deviceLike these steps indicate, the NETIF_F_HW_ESP bit can be cleared afterxfrm_dev_state_add() acquired a reference to "struct net_device".Also, xfrm_dev_state_add() does not check for the NETIF_F_HW_ESP bitwhen acquiring a reference to "struct net_device".Commit 03891f820c21 ("xfrm: handle NETDEV_UNREGISTER for xfrm device")re-introduced the NETDEV_UNREGISTER event to xfrm_dev_event(), but thatcommit for unknown reason chose to share xfrm_dev_down() between theNETDEV_DOWN event and the NETDEV_UNREGISTER event.I guess that that commit missed the behavior in the previous paragraph.Therefore, we need to re-introduce xfrm_dev_unregister() in order torelease the reference to "struct net_device" by unconditionally flushingstate and policy.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43168 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix reflink preserve cleanup issuecommit c06c303832ec ("ocfs2: fix xattr array entry __counted_by error")doesn't handle all cases and the cleanup job for preserved xattr entriesstill has bug:- the 'last' pointer should be shifted by one unit after cleanup an array entry.- current code logic doesn't cleanup the first entry when xh_count is 1.Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43170 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: gadget: Move vbus draw to workqueue contextCurrently dwc3_gadget_vbus_draw() can be called from atomiccontext, which in turn invokes power-supply-core APIs. Andsome these PMIC APIs have operations that may sleep, leadingto kernel panic.Fix this by moving the vbus_draw into a workqueue context.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43171 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:EFI/CPER: don't dump the entire memory regionThe current logic at cper_print_fw_err() doesn't check if theerror record length is big enough to handle offset. On a bad firmware,if the ofset is above the actual record, length -= offset willunderflow, making it dump the entire memory.The end result can be: - the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region.Fix it by checking if the section length is too small before doinga hex dump.[ rjw: Subject tweaks ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43172 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: fix 22000 series SMEM parsingIf the firmware were to report three LMACs (which doesn'texist in hardware) then using "fwrt->smem_cfg.lmac[2]" isan overrun of the array. Reject such and use IWL_FW_CHECKinstead of WARN_ON in this function.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43180 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_modekaweth_set_rx_mode(), the ndo_set_rx_mode callback, callsnetif_stop_queue() and netif_wake_queue(). These are TX queue flowcontrol functions unrelated to RX multicast configuration.The premature netif_wake_queue() can re-enable TX while tx_urb is stillin-flight, leading to a double usb_submit_urb() on the same URB:kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb);}kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done}kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active}This triggers the WARN in usb_submit_urb(): "URB submitted while active"This is a similar class of bug fixed in rtl8150 by- commit 958baf5eaee3 ("net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast").Also kaweth_set_rx_mode() is already functionally broken, thereal set_rx_mode action is performed by kaweth_async_set_rx_mode(),which in turn is not a no-op only at ndo_open() time.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43182 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: ccs: Avoid possible division by zeroCalculating maximum M for scaler configuration involves dividing byMIN_X_OUTPUT_SIZE limit register's value. Albeit the value is presumablynon-zero, the driver was missing the check it in fact was. Fix this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43194 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: consume xmit errors of GSO framesudpgro_frglist.sh and udpgro_bench.sh are the flakiest testscurrently in NIPA. They fail in the same exact way, TCP GROtest stalls occasionally and the test gets killed after 10min.These tests use veth to simulate GRO. They attach a trivial("return XDP_PASS;") XDP program to the veth to force TSO offand NAPI on.Digging into the failure mode we can see that the connectionis completely stuck after a burst of drops. The sender's snd_nxtis at sequence number N [1], but the receiver claims to havereceived (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzleis that senders rtx queue is not empty (let's say the block inthe rtx queue is at sequence number N - 4 * MSS [3]).In this state, sender sends a retransmission from the rtx queuewith a single segment, and sequence numbers N-4*MSS:N-3*MSS [3].Receiver sees it and responds with an ACK all the way up toN + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATAbecause it has no recollection of ever sending data that far out [1].And we are stuck.The root cause is the mess of the xmit return codes. veth returnsan error when it can't xmit a frame. We end up with a loss eventlike this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok | ok ok ok \\ snd_nxt"x" means packet lost by veth, and "ok" means it went thru.Since veth has TSO disabled in this test it sees individual segments.Segment 1 is on the retransmit queue and will be resent.So why did the sender not advance snd_nxt even tho it clearly didsend up to seg 8? tcp_write_xmit() interprets the return codefrom the core to mean that data has not been sent at all. SinceTCP deals with GSO super frames, not individual segment the cruxof the problem is that loss of a single segment can be interpretedas loss of all. TCP only sees the last return code for the lastsegment of the GSO frame (in <> brackets in the diagram above).Of course for the problem to occur we need a setup or a devicewithout a Qdisc. Otherwise Qdisc layer disconnects the protocollayer from the device errors completely.We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-"networks" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix?Similar fix has been proposed by Eric in the past but never committedbecause original reporter was working with an OOT driver and wasn'tproviding feedback (see Link).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43196 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: ti: pruss: Fix double free in pruss_clk_mux_setup()In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectlycalls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np)on the error path. However, after the devm_add_action_or_reset()returns, the of_node_put(clk_mux_np) is called again, causing a doublefree.Fix by returning directly, to avoid the duplicate of_node_put().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43200 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functionsstruct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target);While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specifythe parameters in the correct order, pci_primary_epc_epf_unlink() andpci_secondary_epc_epf_unlink() specify the parameters in the wrong order,leading to the below kernel crash when using the unlink command inconfigfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0[mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43202 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: vt8500lcdfb: fix missing dma_free_coherent()fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is notfreed if the error path is reached.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43204 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: q6asm: drop DSP responses for closed data streams'Commit a354f030dbce ("ASoC: qcom: q6asm: handle the responsesafter closing")' attempted to ignore DSP responses arrivingafter a stream had been closed.However, those responses were still handled, causing lockups.Fix this by unconditionally dropping all DSP responses associated withclosed data streams.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43205 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: validate num_ifs to prevent out-of-bounds writeThe driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes()but never validates it against DPSW_MAX_IF (64). This value controlsiteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indicesinto the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reportsnum_ifs >= 64, the loop can write past the array bounds.Add a bound check for num_ifs in dpaa2_switch_init().dpaa2_switch_fdb_get_flood_cfg() appends the control interface (portnum_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and allports match the flood filter, the loop fills all 64 slots and the controlinterface write overflows by one entry.The check uses >= because num_ifs == DPSW_MAX_IF is also functionallybroken.build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43207 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: mtk-mdp: Fix error handling in probe functionAdd mtk_mdp_unregister_m2m_device() on the error handling path to preventresource leak.Add check for the return value of vpu_get_plat_device() to prevent nullpointer dereference. And vpu_get_plat_device() increases the referencecount of the returned platform device. Add platform_device_put() toprevent reference leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43213 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw89: pci: validate sequence number of TX release reportHardware rarely reports abnormal sequence number in TX release report,which will access out-of-bounds of wd_ring->pages array, causing NULLpointer 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: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1085 Comm: irq/129-rtw89_p Tainted: G S U 6.1.145-17510-g2f3369c91536 #1 (HASH:69e8 1) Call Trace: rtw89_pci_release_tx+0x18f/0x300 [rtw89_pci (HASH:4c83 2)] rtw89_pci_napi_poll+0xc2/0x190 [rtw89_pci (HASH:4c83 2)] net_rx_action+0xfc/0x460 net/core/dev.c:6578 net/core/dev.c:6645 net/core/dev.c:6759 handle_softirqs+0xbe/0x290 kernel/softirq.c:601 ? rtw89_pci_interrupt_threadfn+0xc5/0x350 [rtw89_pci (HASH:4c83 2)] __local_bh_enable_ip+0xeb/0x120 kernel/softirq.c:499 kernel/softirq.c:423 rtw89_pci_interrupt_threadfn+0xf8/0x350 [rtw89_pci (HASH:4c83 2)] ? irq_thread+0xa7/0x340 kernel/irq/manage.c:0 irq_thread+0x177/0x340 kernel/irq/manage.c:1205 kernel/irq/manage.c:1314 ? thaw_kernel_threads+0xb0/0xb0 kernel/irq/manage.c:1202 ? irq_forced_thread_fn+0x80/0x80 kernel/irq/manage.c:1220 kthread+0xea/0x110 kernel/kthread.c:376 ? synchronize_irq+0x1a0/0x1a0 kernel/irq/manage.c:1287 ? kthread_associate_blkcg+0x80/0x80 kernel/kthread.c:331 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 To prevent crash, validate rpp_info.seq before using.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43216 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: Drop the lock in skb_may_tx_timestamp()skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock mustnot be taken in IRQ context, only softirq is okay. A few drivers receivethe timestamp via a dedicated interrupt and complete the TX timestampfrom that handler. This will lead to a deadlock if the lock is alreadywrite-locked on the same CPU.Taking the lock can be avoided. The socket (pointed by the skb) willremain valid until the skb is released. The ->sk_socket and ->filemember will be set to NULL once the user closes the socket which mayhappen before the timestamp arrives.If we happen to observe the pointer while the socket is closing butbefore the pointer is set to NULL then we may use it because bothpointer (and the file's cred member) are RCU freed.Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add amatching WRITE_ONCE() where the pointer are cleared.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43219 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: cpsw_new: Fix potential unregister of netdev that has not been registered yetIf an error occurs during register_netdev() for the first MAC incpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL,cpsw->slaves[1].ndev would remain unchanged. This could later causecpsw_unregister_ports() to attempt unregistering the second MAC.To address this, add a check for ndev->reg_state before callingunregister_netdev(). With this change, setting cpsw->slaves[i].ndevto NULL becomes unnecessary and can be removed accordingly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43225 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix memory leak on failure pathcfg80211_inform_bss_frame() may return NULL on failure. In that case,the allocated buffer 'buf' is not freed and the function returns early,leading to potential memory leak.Fix this by ensuring that 'buf' is freed on both success and failure paths.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43226 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/rds: No shortcut out of RDS_CONN_ERRORRDS connections carry a state "rds_conn_path::cp_state"and transitions from one state to another and are conditionalupon an expected state: "rds_conn_path_transition."There is one exception to this conditionality, which is"RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop"regardless of what state the condition is currently in.But as soon as a connection enters state "RDS_CONN_ERROR",the connection handling code expects it to go through theshutdown-path.The RDS/TCP multipath changes added a shortcut out of"RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING"via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change").A subsequent "rds_tcp_reset_callbacks" can then transitionthe state to "RDS_CONN_RESETTING" with a shutdown-worker queued.That'll trip up "rds_conn_init_shutdown", which wasnever adjusted to handle "RDS_CONN_RESETTING" and subsequentlydrops the connection with the dreaded "DR_INV_CONN_STATE",which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever.So we do two things here:a) Don't shortcut "RDS_CONN_ERROR", but take the longer path through the shutdown code.b) Add "RDS_CONN_RESETTING" to the expected states in "rds_conn_init_shutdown" so that we won't error out and get stuck, if we ever hit weird state transitions like this again."

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43227 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clocksource/drivers/sh_tmu: Always leave device running after probeThe TMU device can be used as both a clocksource and a clockeventprovider. The driver tries to be smart and power itself on and off, aswell as enabling and disabling its clock when it's not in operation.This behavior is slightly altered if the TMU is used as an earlyplatform device in which case the device is left powered on after probe,but the clock is still enabled and disabled at runtime.This has worked for a long time, but recent improvements in PREEMPT_RTand PROVE_LOCKING have highlighted an issue. As the TMU registers itselfas a clockevent provider, clockevents_register_device(), it needs to useraw spinlocks internally as this is the context of which the clockeventframework interacts with the TMU driver. However in the context ofholding a raw spinlock the TMU driver can't really manage its powerstate or clock with calls to pm_runtime_*() and clk_*() as these callsend up in other platform drivers using regular spinlocks to controlpower and clocks.This mix of spinlock contexts trips a lockdep warning. ============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90For non-PREEMPT_RT builds this is not really an issue, but forPREEMPT_RT builds where normal spinlocks can sleep this might be anissue. Be cautious and always leave the power and clock running afterprobe.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43230 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/rds: Clear reconnect pending bitWhen canceling the reconnect worker, care must be taken to reset thereconnect-pending bit. If the reconnect worker has not yet beenscheduled before it is canceled, the reconnect-pending bit will stayon forever.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43231 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: radio-keene: fix memory leak in error pathFix a memory leak in usb_keene_probe(). The v4l2 control handler isinitialized and controls are added, but if v4l2_device_register() orvideo_register_device() fails afterward, the handler was never freed,leaking memory.Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensurethe control handler is properly freed for all error paths after it isinitialized.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43234 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:team: avoid NETDEV_CHANGEMTU event when unregistering slavesyzbot is reporting unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 3 ref_tracker: netdev@ffff88807dcf8618 has 1/2 users at __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline] netdev_hold include/linux/netdevice.h:4429 [inline] inetdev_init+0x201/0x4e0 net/ipv4/devinet.c:286 inetdev_event+0x251/0x1610 net/ipv4/devinet.c:1600 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_mtu net/core/dev.c:2318 [inline] netif_set_mtu_ext+0x5aa/0x800 net/core/dev.c:9886 netif_set_mtu+0xd7/0x1b0 net/core/dev.c:9907 dev_set_mtu+0x126/0x260 net/core/dev_api.c:248 team_port_del+0xb07/0xcb0 drivers/net/team/team_core.c:1333 team_del_slave drivers/net/team/team_core.c:1936 [inline] team_device_event+0x207/0x5b0 drivers/net/team/team_core.c:2929 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2281 [inline] call_netdevice_notifiers net/core/dev.c:2295 [inline] __dev_change_net_namespace+0xcb7/0x2050 net/core/dev.c:12592 do_setlink+0x2ce/0x4590 net/core/rtnetlink.c:3060 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x15a9/0x1be0 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894problem. Ido Schimmel found steps to reproduce ip link add name team1 type team ip link add name dummy1 mtu 1499 master team1 type dummy ip netns add ns1 ip link set dev dummy1 netns ns1 ip -n ns1 link del dev dummy1and also found that the same issue was fixed in the bond driver incommit f51048c3e07b ("bonding: avoid NETDEV_CHANGEMTU event whenunregistering slave").Let's do similar thing for the team driver, with commit ad7c7b2172c3 ("net:hold netdev instance lock during sysfs operations") and commit 303a8487a657("net: s/__dev_set_mtu/__netif_set_mtu/") also applied.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43236 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after releaseThe atmel_hlcdc_plane_atomic_duplicate_state() callback was copyingthe atmel_hlcdc_plane state structure without properly duplicating thedrm_plane_state. In particular, state->commit remained set to the oldstate commit, which can lead to a use-after-free in the nextdrm_atomic_commit() call.Fix this by calling__drm_atomic_helper_duplicate_plane_state(), which correctly clonesthe base drm_plane_state (including the ->commit pointer).It has been seen when closing and re-opening the device node whileanother DRM client (e.g. fbdev) is still attached:=============================================================================BUG kmalloc-64 (Not tainted): Poison overwritten-----------------------------------------------------------------------------0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6bFIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6bAllocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0pid=29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0pid=169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0flags=0x200(workingset|zone=0)Object 0xc611b340 @offset=832 fp=0xc611b7c0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43239 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: prevent races in ->query_interfaces()It was possible for two query interface works to be concurrently tryingto update the interfaces.Prevent this by checking and updating iface_last_update underiface_lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43244 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kcm: fix zero-frag skb in frag_list on partial sendmsg errorSyzkaller reported a warning in kcm_write_msgs() when processing amessage with a zero-fragment skb in the frag_list.When kcm_sendmsg() fills MAX_SKB_FRAGS fragments in the current skb,it allocates a new skb (tskb) and links it into the frag_list beforecopying data. If the copy subsequently fails (e.g. -EFAULT fromuser memory), tskb remains in the frag_list with zero fragments: head skb (msg being assembled, NOT yet in sk_write_queue) +-----------+ | frags[17] | (MAX_SKB_FRAGS, all filled with data) | frag_list-+--> tskb +-----------+ +----------+ | frags[0] | (empty! copy failed before filling) +----------+For SOCK_SEQPACKET with partial data already copied, the error pathsaves this message via partial_message for later completion. ForSOCK_SEQPACKET, sock_write_iter() automatically sets MSG_EOR, so asubsequent zero-length write(fd, NULL, 0) completes the message andqueues it to sk_write_queue. kcm_write_msgs() then walks thefrag_list and hits: WARN_ON(!skb_shinfo(skb)->nr_frags)TCP has a similar pattern where skbs are enqueued before data copyand cleaned up on failure via tcp_remove_empty_skb(). KCM wasmissing the equivalent cleanup.Fix this by tracking the predecessor skb (frag_prev) when allocatinga new frag_list entry. On error, if the tail skb has zero frags,use frag_prev to unlink and free it in O(1) without walking thesingly-linked frag_list. frag_prev is safe to dereference becausethe entire message chain is only held locally (or in kcm->seq_skb)and is not added to sk_write_queue until MSG_EOR, so the send pathcannot free it underneath us.Also change the WARN_ON to WARN_ON_ONCE to avoid flooding the logif the condition is somehow hit repeatedly.There are currently no KCM selftests in the kernel tree; a simplereproducer is available at [1].[1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43246 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c/tw9906: Fix potential memory leak in tw9906_probe()In one of the error paths in tw9906_probe(), the memory allocated inv4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix thatby calling v4l2_ctrl_handler_free() on the handler in that error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43257 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: cx88: Add missing unmap in snd_cx88_hw_params()In error path, add cx88_alsa_dma_unmap() to releaseresource acquired by cx88_alsa_dma_map().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43261 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: Add support for TSV110 Spectre-BHB mitigationThe TSV110 processor is vulnerable to the Spectre-BHB (Branch HistoryBuffer) attack, which can be exploited to leak information throughbranch prediction side channels. This commit adds the MIDR of TSV110to the list for software mitigation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43262 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: fiemap page fault fixIn gfs2_fiemap(), we are calling iomap_fiemap() while holding the inodeglock. This can lead to recursive glock taking if the fiemap buffer ismemory mapped to the same inode and accessing it triggers a page fault.Fix by disabling page faults for iomap_fiemap() and faulting in thebuffer by hand if necessary.Fixes xfstest generic/742.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43266 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:EFI/CPER: don't go past the ARM processor CPER record bufferThere's a logic inside GHES/CPER to detect if the section_lengthis too small, but it doesn't detect if it is too big.Currently, if the firmware receives an ARM processor CPER recordstating that a section length is big, kernel will blindly trustsection_length, producing a very long dump. For instance, a 67bytes record with ERR_INFO_NUM set 46198 and section lengthset to 854918320 would dump a lot of data going a way past thefirmware memory-mapped area.Fix it by adding a logic to prevent it to go past the bufferif ERR_INFO_NUM is too big, making it report instead: [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 [Hardware Error]: event severity: recoverable [Hardware Error]: Error 0, type: recoverable [Hardware Error]: section_type: ARM processor error [Hardware Error]: MIDR: 0xff304b2f8476870a [Hardware Error]: section length: 854918320, CPER size: 67 [Hardware Error]: section length is too big [Hardware Error]: firmware-generated error record is incorrect [Hardware Error]: ERR_INFO_NUM is 46198[ rjw: Subject and changelog tweaks ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43270 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove()In mtk_mdp_probe(), vpu_get_plat_device() increases the referencecount of the returned platform device. Add platform_device_put()to prevent reference leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43273 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ceph: supply snapshot context in ceph_zero_partial_object()The ceph_zero_partial_object function was missing proper snapshotcontext for its OSD write operations, which could lead to datainconsistencies in snapshots.Reproducer:../src/vstart.sh --new -x --localhost --bluestore./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a'mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.confdd if=/dev/urandom of=/mnt/mycephfs/foo bs=64K count=1mkdir /mnt/mycephfs/.snap/snap1md5sum /mnt/mycephfs/.snap/snap1/foofallocate -p -o 0 -l 4096 /mnt/mycephfs/fooecho 3 > /proc/sys/vm/drop/cachesmd5sum /mnt/mycephfs/.snap/snap1/foo # get different md5sum!!

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43275 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Flush exception handling work when RPM level is zeroEnsure that the exception event handling work is explicitly flushed duringsuspend when the runtime power management level is set to UFS_PM_LVL_0.When the RPM level is zero, the device power mode and link state bothremain active. Previously, the UFS core driver bypassed flushing exceptionevent handling jobs in this configuration. This created a race conditionwhere the driver could attempt to access the host controller to handle anexception after the system had already entered a deep power-down state,resulting in a system crash.Explicitly flush this work and disable auto BKOPs before the suspendcallback proceeds. This guarantees that pending exception tasks completeand prevents illegal hardware access during the power-down sequence.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43277 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:APEI/GHES: ensure that won't go past CPER allocated recordThe logic at ghes_new() prevents allocating too large records, bychecking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB).Yet, the allocation is done with the actual number of pages from theCPER bios table location, which can be smaller.Yet, a bad firmware could send data with a different size, which mightbe bigger than the allocated memory, causing an OOPS: Unable to handle kernel paging request at virtual address fff00000f9b40000 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 swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000 [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 Workqueue: kacpi_notify acpi_os_execute_deferred pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : hex_dump_to_buffer+0x30c/0x4a0 lr : hex_dump_to_buffer+0x328/0x4a0 sp : ffff800080e13880 x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083 x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004 x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083 x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010 x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008 x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020 x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000 x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008 Call trace: hex_dump_to_buffer+0x30c/0x4a0 (P) print_hex_dump+0xac/0x170 cper_estatus_print_section+0x90c/0x968 cper_estatus_print+0xf0/0x158 __ghes_print_estatus+0xa0/0x148 ghes_proc+0x1bc/0x220 ghes_notify_hed+0x5c/0xb8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x80 acpi_hed_notify+0x28/0x40 acpi_ev_notify_dispatch+0x50/0x80 acpi_os_execute_deferred+0x24/0x48 process_one_work+0x15c/0x3b0 worker_thread+0x2d0/0x400 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44) ---[ end trace 0000000000000000 ]---Prevent that by taking the actual allocated are into account whenchecking for CPER length.[ rjw: Subject tweaks ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43279 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Add sanity check for OOB writes at silencingAt silencing the playback URB packets in the implicit fb mode beforethe actual playback, we blindly assume that the received packets fitwith the buffer size. But when the setup in the capture streamdiffers from the playback stream (e.g. due to the USB core limitationof max packet size), such an inconsistency may lead to OOB writes tothe buffer, resulting in a crash.For addressing it, add a sanity check of the transfer buffer size atprepare_silent_urb(), and stop the data copy if the received dataoverflows. Also, report back the transfer error properly from there,too.Note that this doesn't fix the root cause of the playback erroritself, but this merely covers the kernel Oops.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43281 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate()Although it is guided that `#mbox-cells` must be at least 1, there aremany instances of `#mbox-cells = <0>;` in the device tree. If that isthe case and the corresponding mailbox controller does not provide`fw_xlate` and of_xlate` function pointers, `fw_mbox_index_xlate()` willbe used by default and out-of-bounds accesses could occur due to lack ofbounds check in that function.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43283 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: ec_bhf: Fix dma_free_coherent() dma handledma_free_coherent() in error path takes priv->rx_buf.alloc_len asthe dma handle. This would lead to improper unmapping of the buffer.Change the dma handle to priv->rx_buf.alloc_phys.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43287 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm: Account property blob allocations to memcgDRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sizedproperty blobs backed by kernel memory.Currently, the blob data allocation is not accounted to the allocatingprocess's memory cgroup, allowing unprivileged users to trigger unboundedkernel memory consumption and potentially cause system-wide OOM.Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memoryis properly charged to the caller's memcg. This ensures existing cgroupmemory limits apply and prevents uncontrolled kernel memory growth withoutintroducing additional policy or per-file limits.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43288 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: move ext4_percpu_param_init() before ext4_mb_init()When running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the`DOUBLE_CHECK` macro defined, the following panic is triggered:==================================================================EXT4-fs error (device vdc): ext4_validate_block_bitmap:423: comm mount: bg 0: bad block bitmap checksumBUG: unable to handle page fault for address: ff110000fa2cc000PGD 3e01067 P4D 3e02067 PUD 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none)RIP: 0010:percpu_counter_add_batch+0x13/0xa0Call Trace: ext4_mark_group_bitmap_corrupted+0xcb/0xe0 ext4_validate_block_bitmap+0x2a1/0x2f0 ext4_read_block_bitmap+0x33/0x50 mb_group_bb_bitmap_alloc+0x33/0x80 ext4_mb_add_groupinfo+0x190/0x250 ext4_mb_init_backend+0x87/0x290 ext4_mb_init+0x456/0x640 __ext4_fill_super+0x1072/0x1680 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4f6/0x6b0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e==================================================================This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/testWith DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() readsand validates the block bitmap. When the validation fails,ext4_mark_group_bitmap_corrupted() attempts to updatesbi->s_freeclusters_counter. However, this percpu_counter has not beeninitialized yet at this point, which leads to the panic described above.Fix this by moving the execution of ext4_percpu_param_init() to occurbefore ext4_mb_init(), ensuring the per-CPU counters are initializedbefore they are used.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43295 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net()When idtab allocation fails, net is not registered with rio_add_net() yet,so kfree(net) is sufficient to release the memory. Set mport->net to NULLto avoid dangling pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43296 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: Workaround SQM/PSE stalls by disabling stickyNIX SQ manager sticky mode is known to cause stalls when multiple SQsshare an SMQ and transmit concurrently. Additionally, PSE may deadlockon transitions between sticky and non-sticky transmissions. There isalso a credit drop issue observed when certain condition clocks aregated.work around these hardware errata by:- Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14)- Disabling sticky -> non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23)- Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21)These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With thisconfiguration the SQM/PSE maintain forward progress under load withoutcredit loss, at the cost of disabling sticky optimizations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43299 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure()[BUG]There is a bug report that when btrfs hits ENOSPC error in a criticalpath, btrfs flips RO (this part is expected, although the ENOSPC bugstill needs to be addressed).The problem is after the RO flip, if there is a read repair pending, wecan hit the ASSERT() inside btrfs_repair_io_failure() like the following: BTRFS info (device vdc): relocating block group 30408704 flags metadata|raid1 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -28) WARNING: fs/btrfs/extent-tree.c:3235 at __btrfs_free_extent.isra.0+0x453/0xfd0, CPU#1: btrfs/383844 Modules linked in: kvm_intel kvm irqbypass [...] ---[ end trace 0000000000000000 ]--- BTRFS info (device vdc state EA): 2 enospc errors during balance BTRFS info (device vdc state EA): balance: ended with status: -30 BTRFS error (device vdc state EA): parent transid verify failed on logical 30556160 mirror 2 wanted 8 found 6 BTRFS error (device vdc state EA): bdev /dev/nvme0n1 errs: wr 0, rd 0, flush 0, corrupt 10, gen 0 [...] assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938 ------------[ cut here ]------------ assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938 kernel BUG at fs/btrfs/bio.c:938! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 868 Comm: kworker/u8:13 Tainted: G W N 6.19.0-rc6+ #4788 PREEMPT(full) Tainted: [W]=WARN, [N]=TEST Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 Workqueue: btrfs-endio simple_end_io_work RIP: 0010:btrfs_repair_io_failure.cold+0xb2/0x120 RSP: 0000:ffffc90001d2bcf0 EFLAGS: 00010246 RAX: 0000000000000051 RBX: 0000000000001000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8305cf42 RDI: 00000000ffffffff RBP: 0000000000000002 R08: 00000000fffeffff R09: ffffffff837fa988 R10: ffffffff8327a9e0 R11: 6f69747265737361 R12: ffff88813018d310 R13: ffff888168b8a000 R14: ffffc90001d2bd90 R15: ffff88810a169000 FS: 0000000000000000(0000) GS:ffff8885e752c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 ------------[ cut here ]------------[CAUSE]The cause of -ENOSPC error during the test case btrfs/124 is stillunknown, although it's known that we still have cases where metadata canbe over-committed but can not be fulfilled correctly, thus if we hitsuch ENOSPC error inside a critical path, we have no choice but abortthe current transaction.This will mark the fs read-only.The problem is inside the btrfs_repair_io_failure() path that we requirethe fs not to be mount read-only. This is normally fine, but if we aredoing a read-repair meanwhile the fs flips RO due to a critical error,we can enter btrfs_repair_io_failure() with super block set toread-only, thus triggering the above crash.[FIX]Just replace the ASSERT() with a proper return if the fs is alreadyread-only.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43302 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Set DMA segment size to avoid debug warningsWhen using V3D rendering with CONFIG_DMA_API_DEBUG enabled, thekernel occasionally reports a segment size mismatch. This is because'max_seg_size' is not set. The kernel defaults to 64K. setting'max_seg_size' to the maximum will prevent 'debug_dma_map_sg()'from complaining about the over-mapping of the V3D segment length.DMA-API: v3d 1002000000.v3d: mapping sg segment longer than device claims to support [len=8290304] [max=65536]WARNING: CPU: 0 PID: 493 at kernel/dma/debug.c:1179 debug_dma_map_sg+0x330/0x388CPU: 0 UID: 0 PID: 493 Comm: Xorg Not tainted 6.12.53-yocto-standard #1Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : debug_dma_map_sg+0x330/0x388lr : debug_dma_map_sg+0x330/0x388sp : ffff8000829a3ac0x29: ffff8000829a3ac0 x28: 0000000000000001 x27: ffff8000813fe000x26: ffffc1ffc0000000 x25: ffff00010fdeb760 x24: 0000000000000000x23: ffff8000816a9bf0 x22: 0000000000000001 x21: 0000000000000002x20: 0000000000000002 x19: ffff00010185e810 x18: ffffffffffffffffx17: 69766564206e6168 x16: 74207265676e6f6c x15: 20746e656d676573x14: 20677320676e6970 x13: 5d34303334393134 x12: 0000000000000000x11: 00000000000000c0 x10: 00000000000009c0 x9 : ffff8000800e0b7cx8 : ffff00010a315ca0 x7 : ffff8000816a5110 x6 : 0000000000000001x5 : 000000000000002b x4 : 0000000000000002 x3 : 0000000000000008x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00010a315280Call trace: debug_dma_map_sg+0x330/0x388 __dma_map_sg_attrs+0xc0/0x278 dma_map_sgtable+0x30/0x58 drm_gem_shmem_get_pages_sgt+0xb4/0x140 v3d_bo_create_finish+0x28/0x130 [v3d] v3d_create_bo_ioctl+0x54/0x180 [v3d] drm_ioctl_kernel+0xc8/0x140 drm_ioctl+0x2d4/0x4d8

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43304 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: define and enforce CEPH_MAX_KEY_LENWhen decoding the key, verify that the key material would fit intoa fixed-size buffer in process_auth_done() and generally has a sanelength.The new CEPH_MAX_KEY_LEN check replaces the existing check for a keywith no key material which is a) not universal since CEPH_CRYPTO_NONEhas to be excluded and b) doesn't provide much value since a smallerthan needed key is just as invalid as no key -- this has to be handledelsewhere anyway.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43308 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't BUG() on unexpected delayed ref type in run_one_delayed_ref()There is no need to BUG(), we can just return an error and log an errormessage.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43309 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md raid: fix hang when stopping arrays with metadata through dm-raidWhen using device-mapper's dm-raid target, stopping a RAID array can causethe system to hang under specific conditions.This occurs when:- A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices)- The top-level RAID device is then removedRemoving the top-level device triggers a hang in the following sequence:the dm-raid destructor calls md_stop(), which tries to flush thewrite-intent bitmap by writing to the metadata sub-devices. However, thesedevices are already suspended, making them unable to complete the write-intentoperations and causing an indefinite block.Fix:- Prevent bitmap flushing when md_stop() is called from dm-raiddestructor context and avoid a quiescing/unquescing cycle which could also cause I/O- Still allow write-intent bitmap flushing when called from dm-raidsuspend contextThis ensures that RAID array teardown can complete successfully even when theunderlying devices are in a suspended state.This second patch uses md_is_rdwr() to distinguish between suspend anddestructor paths as elaborated on above.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43310 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVCFor the i.MX8MQ platform, there is a hardware limitation: the g1 VPU andg2 VPU cannot decode simultaneously; otherwise, it will cause below buserror and produce corrupted pictures, even potentially lead to system hang.[ 110.527986] hantro-vpu 38310000.video-codec: frame decode timed out.[ 110.583517] hantro-vpu 38310000.video-codec: bus error detected.Therefore, it is necessary to ensure that g1 and g2 operate alternately.This allows for successful multi-instance decoding of H.264 and HEVC.To achieve this, g1 and g2 share the same v4l2_m2m_dev, and then thev4l2_m2m_dev can handle the scheduling.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43312 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: ov5647: Initialize subdev before controlsIn ov5647_init_controls() we call v4l2_get_subdevdata, but it isinitialized by v4l2_i2c_subdev_init() in the probe, which currentlyhappens after init_controls(). This can result in a segfault if theerror condition is hit, and we try to access i2c_client, so fix theorder.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43313 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4()In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDEdevice and then reassigned an ISA device: dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...); dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...);If the first lookup succeeds but the second fails, dev becomes NULL. Thisleads to a potential null-pointer dereference when dev_dbg() is called: if (errata.piix4.bmisx) dev_dbg(&dev->dev, ...);To prevent this, use two temporary pointers and retrieve each deviceindependently, avoiding overwriting dev with a possible NULL value.[ rjw: Subject adjustment, added an empty code line ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43314 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm: remove fake timeout to avoid leak requestSince commit 15f73f5b3e59 ("blk-mq: move failure injection out ofblk_mq_complete_request"), drivers are responsible for callingblk_should_fake_timeout() at appropriate code paths and opportunities.However, the dm driver does not implement its own timeout handler andrelies on the timeout handling of its slave devices.If an io-timeout-fail error is injected to a dm device, the requestwill be leaked and never completed, causing tasks to hang indefinitely.Reproduce:1. prepare dm which has iscsi slave device2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times3. read/write dm4. iscsiadm -m node -uResult: hang task like below[ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds.[ 862.244133] Tainted: G E 6.19.0-rc1+ #51[ 862.244337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.[ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000[ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi][ 862.245264] Call Trace:[ 862.245587] [ 862.245814] __schedule+0x810/0x15c0[ 862.246557] schedule+0x69/0x180[ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120[ 862.247688] elevator_change+0x16d/0x460[ 862.247893] elevator_set_none+0x87/0xf0[ 862.248798] blk_unregister_queue+0x12e/0x2a0[ 862.248995] __del_gendisk+0x231/0x7e0[ 862.250143] del_gendisk+0x12f/0x1d0[ 862.250339] sd_remove+0x85/0x130 [sd_mod][ 862.250650] device_release_driver_internal+0x36d/0x530[ 862.250849] bus_remove_device+0x1dd/0x3f0[ 862.251042] device_del+0x38a/0x930[ 862.252095] __scsi_remove_device+0x293/0x360[ 862.252291] scsi_remove_target+0x486/0x760[ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi][ 862.252886] process_one_work+0x633/0xe50[ 862.253101] worker_thread+0x6df/0xf10[ 862.253647] kthread+0x36d/0x720[ 862.254533] ret_from_fork+0x2a6/0x470[ 862.255852] ret_from_fork_asm+0x1a/0x30[ 862.256037] Remove the blk_should_fake_timeout() check from dm, as dm has nonative timeout handling and should not attempt to fake timeouts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43315 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: nSVM: Remove a user-triggerable WARN on nested_svm_load_cr3() succeedingDrop the WARN in svm_set_nested_state() on nested_svm_load_cr3() failingas it is trivially easy to trigger from userspace by modifying CPUID afterloading CR3. E.g. modifying the state restoration selftest like so: --- tools/testing/selftests/kvm/x86/state_test.c +++ tools/testing/selftests/kvm/x86/state_test.c @@ -280,7 +280,16 @@ int main(int argc, char *argv[]) /* Restore state in a new VM. */ vcpu = vm_recreate_with_one_vcpu(vm); - vcpu_load_state(vcpu, state); + + if (stage == 4) { + state->sregs.cr3 = BIT(44); + vcpu_load_state(vcpu, state); + + vcpu_set_cpuid_property(vcpu, X86_PROPERTY_MAX_PHY_ADDR, 36); + __vcpu_nested_state_set(vcpu, &state->nested); + } else { + vcpu_load_state(vcpu, state); + } /* * Restore XSAVE state in a dummy vCPU, first without doinggenerates: WARNING: CPU: 30 PID: 938 at arch/x86/kvm/svm/nested.c:1877 svm_set_nested_state+0x34a/0x360 [kvm_amd] Modules linked in: kvm_amd kvm irqbypass [last unloaded: kvm] CPU: 30 UID: 1000 PID: 938 Comm: state_test Tainted: G W 6.18.0-rc7-58e10b63777d-next-vm Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_set_nested_state+0x34a/0x360 [kvm_amd] Call Trace: kvm_arch_vcpu_ioctl+0xf33/0x1700 [kvm] kvm_vcpu_ioctl+0x4e6/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x61/0xad0 entry_SYSCALL_64_after_hwframe+0x4b/0x53Simply delete the WARN instead of trying to prevent userspace from shoving"illegal" state into CR3. For better or worse, KVM's ABI allows userspaceto set CPUID after SREGS, and vice versa, and KVM is very permissive whenit comes to guest CPUID. I.e. attempting to enforce the virtual CPU modelwhen setting CPUID could break userspace. Given that the WARN doesn'tprovide any meaningful protection for KVM or benefit for userspace, simplydrop it even though the odds of breaking userspace are minuscule.Opportunistically delete a spurious newline.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43317 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:most: core: fix leak on early registration failureA recent commit fixed a resource leak on early registration failures butfor some reason left out the first error path which still leaks theresources associated with the interface.Fix up also the first error path so that the interface is alwaysreleased on errors.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43318 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix sync handling in amdgpu_dma_buf_move_notifyInvalidating a dmabuf will impact other users of the shared BO.In the scenario where process A moves the BO, it needs to informprocess B about the move and process B will need to update itspage table.The commit fixes a synchronisation bug caused by the use of theticket: it made amdgpu_vm_handle_moved behave as if updatingthe page table immediately was correct but in this case it's not.An example is the following scenario, with 2 GPUs and glxgearsrunning on GPU0 and Xorg running on GPU1, on a system where P2PPCI isn't supported:glxgears: export linear buffer from GPU0 and import using GPU1 submit frame rendering to GPU0 submit tiled->linear blitXorg: copy of linear bufferThe sequence of jobs would be: drm_sched_job_run # GPU0, frame rendering drm_sched_job_queue # GPU0, blit drm_sched_job_done # GPU0, frame rendering drm_sched_job_run # GPU0, blit move linear buffer for GPU1 access # amdgpu_dma_buf_move_notify -> update pt # GPU0It this point the blit job on GPU0 is still running and wouldlikely produce a page fault.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43324 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: dummy-hcd: Fix interrupt synchronization errorThis fixes an error in synchronization in the dummy-hcd driver. Theerror has a somewhat involved history. The synchronization mechanismwas introduced by commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneoussynchronization change"), which added an emulated "interrupts enabled"flag together with code emulating synchronize_irq() (it waits untilall current handler callbacks have returned).But the emulated interrupt-disable occurred too late, after the drivercontaining the handler callback routines had been told that it wasunbound and no more callbacks would occur. Commit 4a5d797a9f9c ("usb:gadget: dummy_hcd: fix gpf in gadget_setup") tried to fix this bymoving the synchronize_irq() emulation code from dummy_stop() todummy_pullup(), which runs before the unbind callback.There still were races, though, because the emulated interrupt-disablestill occurred too late. It couldn't be moved to dummy_pullup(),because that routine can be called for reasons other than an impendingunbind. Therefore commits 7dc0c55e9f30 ("USB: UDC core: Addudc_async_callbacks gadget op") and 04145a03db9d ("USB: UDC: Implementudc_async_callbacks in dummy-hcd") added an API allowing the UDC coreto tell dummy-hcd exactly when emulated interrupts and their callbacksshould be disabled.That brings us to the current state of things, which is still wrongbecause the emulated synchronize_irq() occurs before the emulatedinterrupt-disable! That's no good, beause it means that more emulatedinterrupts can occur after the synchronize_irq() emulation has run,leading to the possibility that a callback handler may be running whenthe gadget driver is unbound.To fix this, we have to move the synchronize_irq() emulation code yetagain, to the dummy_udc_async_callbacks() routine, which takes care ofenabling and disabling emulated interrupt requests. Thesynchronization will now run immediately after emulated interrupts aredisabled, which is where it belongs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43327 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: dummy-hcd: Fix locking/synchronization errorSyzbot testing was able to provoke an addressing exception and crashin the usb_gadget_udc_reset() routine indrivers/usb/gadgets/udc/core.c, resulting from the fact that theroutine was called with a second ("driver") argument of NULL. The badcaller was set_link_state() in dummy_hcd.c, and the problem arosebecause of a race between a USB reset and driver unbind.These sorts of races were not supposed to be possible; commit7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"),along with a few followup commits, was written specifically to preventthem. As it turns out, there are (at least) two errors remaining inthe code. Another patch will address the second error; this one isconcerned with the first.The error responsible for the syzbot crash occurred because thestop_activity() routine will sometimes drop and then re-acquire thedum->lock spinlock. A call to stop_activity() occurs inset_link_state() when handling an emulated USB reset, after the testof dum->ints_enabled and before the increment of dum->callback_usage.This allowed another thread (doing a driver unbind) to sneak in andgrab the spinlock, and then clear dum->ints_enabled and dum->driver.Normally this other thread would have to wait for dum->callback_usageto go down to 0 before it would clear dum->driver, but in this case itdidn't have to wait since dum->callback_usage had not yet beenincremented.The fix is to increment dum->callback_usage _before_ callingstop_activity() instead of after. Then the thread doing the unbindwill not clear dum->driver until after the call tousb_gadget_udc_reset() safely returns and dum->callback_usage has beendecremented again.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43328 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error pathWhen kobject_init_and_add() fails, cpufreq_dbs_governor_init() callskobject_put(&dbs_data->attr_set.kobj).The kobject release callback cpufreq_dbs_data_release() callsgov->exit(dbs_data) and kfree(dbs_data), but the current error paththen calls gov->exit(dbs_data) and kfree(dbs_data) again, causing adouble free.Keep the direct kfree(dbs_data) for the gov->init() failure path, butafter kobject_init_and_add() has been called, let kobject_put() handlethe cleanup through cpufreq_dbs_data_release().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43339 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: prevent possible UaF in addrconf_permanent_addr()The mentioned helper try to warn the user about an exceptionalcondition, but the message is delivered too late, accessing the ipv6after its possible deletion.Reorder the statement to avoid the possible UaF; while at it, place thewarning outside the idev->lock as it needs no protection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43342 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_rndis: Protect RNDIS options with mutexThe class/subclass/protocol options are suspectible to race conditionsas they can be accessed concurrently through configfs.Use existing mutex to protect these options. This issue was identifiedduring code inspection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43343 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_subset: Fix unbalanced refcnt in geth_freegeth_alloc() increments the reference count, but geth_free() fails todecrement it. This prevents the configuration of attributes via configfsafter unlinking the function.Decrement the reference count in geth_free() to ensure proper cleanup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43352 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i3c: mipi-i3c-hci: Correct RING_CTRL_ABORT handling in DMA dequeueThe logic used to abort the DMA ring contains several flaws: 1. The driver unconditionally issues a ring abort even when the ring has already stopped. 2. The completion used to wait for abort completion is never re-initialized, resulting in incorrect wait behavior. 3. The abort sequence unintentionally clears RING_CTRL_ENABLE, which resets hardware ring pointers and disrupts the controller state. 4. If the ring is already stopped, the abort operation should be considered successful without attempting further action.Fix the abort handling by checking whether the ring is running beforeissuing an abort, re-initializing the completion when needed, ensuring thatRING_CTRL_ENABLE remains asserted during abort, and treating an alreadystopped ring as a successful condition.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43355 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: bh1780: fix PM runtime leak on error pathMove pm_runtime_put_autosuspend() before the error check to ensurethe PM runtime reference count is always decremented afterpm_runtime_get_sync(), regardless of whether the read operationsucceeds or fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43363 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/apic: Disable x2apic on resume if the kernel expects soWhen resuming from s2ram, firmware may re-enable x2apic mode, which may havebeen disabled by the kernel during boot either because it doesn't support IRQremapping or for other reasons. This causes the kernel to continue using thexapic interface, while the hardware is in x2apic mode, which causes hangs.This happens on defconfig + bare metal + s2ram.Fix this in lapic_resume() by disabling x2apic if the kernel expects it to bedisabled, i.e. when x2apic_mode = 0.The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either thepre-sleep configuration or initial boot configuration for each CPU, includingMSR state: When executing from the power-on reset vector as a result of waking from an S2 or S3 sleep state, the platform firmware performs only the hardware initialization required to restore the system to either the state the platform was in prior to the initial operating system boot, or to the pre-sleep configuration state. In multiprocessor systems, non-boot processors should be placed in the same state as prior to the initial operating system boot. (further ahead) If this is an S2 or S3 wake, then the platform runtime firmware restores minimum context of the system before jumping to the waking vector. This includes: CPU configuration. Platform runtime firmware restores the pre-sleep configuration or initial boot configuration of each CPU (MSR, MTRR, firmware update, SMBase, and so on). Interrupts must be disabled (for IA-32 processors, disabled by CLI instruction). (and other things)So at least as per the spec, re-enablement of x2apic by the firmware isallowed if "x2apic on" is a part of the initial boot configuration. [1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization [ bp: Massage. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43370 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix use-after-free race in VM acquireReplace non-atomic vm->process_info assignment with cmpxchg()to prevent race when parent/child processes sharing a drm_fileboth try to acquire the same VM after fork().(cherry picked from commit c7c573275ec20db05be769288a3e3bb2250ec618)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43373 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ncsi: fix skb leak in error pathsEarly return paths in NCSI RX and AEN handlers fail to releasethe received skb, resulting in a memory leak.Specifically, ncsi_aen_handler() returns on invalid AEN packetswithout consuming the skb. Similarly, ncsi_rcv_rsp() exits earlywhen failing to resolve the NCSI device, response handler, orrequest, leaving the skb unfreed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43380 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs readThe q54sj108a2_debugfs_read function suffers from a stack buffer overflowdue to incorrect arguments passed to bin2hex(). The function currentlypasses 'data' as the destination and 'data_char' as the source.Because bin2hex() converts each input byte into two hex characters, a32-byte block read results in 64 bytes of output. Since 'data' is only34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the endof the buffer onto the stack.Additionally, the arguments were swapped: it was reading from thezero-initialized 'data_char' and writing to 'data', resulting inall-zero output regardless of the actual I2C read.Fix this by:1. Expanding 'data_char' to 66 bytes to safely hold the hex output.2. Correcting the bin2hex() argument order and using the actual read count.3. Using a pointer to select the correct output buffer for the final simple_read_from_buffer call.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43381 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nouveau/dpcd: return EBUSY for aux xfer if the device is asleepIf we have runtime suspended, and userspace wants to use /dev/drm_dp_*then just tell it the device is busy instead of crashing in the GSPcode.WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy)Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]This is a simple fix to get backported. We should probably engineer aproper power domain solution to wake up devices and keep them awakewhile fw updates are happening.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43383 Severity: Moderate CVSS3 score: 5.5

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

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43386 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ieThe current code checks 'i + 5 < in_len' at the end of the if statement.However, it accesses 'in_ie[i + 5]' before that check, which can leadto an out-of-bounds read. Move the length check to the beginning of theconditional to ensure the index is within bounds before accessing thearray.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43387 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: properly validate the data in rtw_get_ie_ex()Just like in commit 154828bf9559 ("staging: rtl8723bs: fix out-of-boundsread in rtw_get_ie() parser"), we don't trust the data in the frame sowe should check the length better before acting on it

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43405 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: Use u32 for non-negative values in ceph_monmap_decode()This patch fixes unnecessary implicit conversions that change signednessof blob_len and num_mon in ceph_monmap_decode().Currently blob_len and num_mon are (signed) int variables. They are usedto hold values that are always non-negative and get assigned inceph_decode_32_safe(), which is meant to assign u32 values. Bothvariables are subsequently used as unsigned values, and the value ofnum_mon is further assigned to monmap->num_mon, which is of type u32.Therefore, both variables should be of type u32. This is especiallyrelevant for num_mon. If the value read from the incoming message isvery large, it is interpreted as a negative value, and the check fornum_mon > CEPH_MAX_MON does not catch it. This leads to the attempt toallocate a very large chunk of memory for monmap, which will most likelyfail. In this case, an unnecessary attempt to allocate memory isperformed, and -ENOMEM is returned instead of -EINVAL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43406 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 process_message_header()If the message frame is (maliciously) corrupted in a way that thelength of the control segment ends up being less than the size of themessage header or a different frame is made to look like a messageframe, out-of-bounds reads may ensue in process_message_header().Perform an explicit bounds check before decoding the message header.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43407 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply()This patch fixes an out-of-bounds access in ceph_handle_auth_reply()that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. Inceph_handle_auth_reply(), the value of the payload_len field of such amessage is stored in a variable of type int. A value greater thanINT_MAX leads to an integer overflow and is interpreted as a negativevalue. This leads to decrementing the pointer address by this value andsubsequently accessing it because ceph_decode_need() only checks thatthe memory access does not exceed the end address of the allocation.This patch fixes the issue by changing the data type of payload_len tou32. Additionally, the data type of result_msg_len is changed to u32,as it is also a variable holding a non-negative length.Also, an additional layer of sanity checks is introduced, ensuring thatdirectly after reading it from the message, payload_len andresult_msg_len are not greater than the overall segment length.BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph]Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014Workqueue: ceph-msgr ceph_con_workfn [libceph]Call Trace: dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x620 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x72/0x210 kasan_report+0xe7/0x130 ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] __asan_report_load_n_noabort+0xf/0x20 ceph_handle_auth_reply+0x642/0x7a0 [libceph] mon_dispatch+0x973/0x23d0 [libceph] ? apparmor_socket_recvmsg+0x6b/0xa0 ? __pfx_mon_dispatch+0x10/0x10 [libceph] ? __kasan_check_write+0x14/0x30i ? mutex_unlock+0x7f/0xd0 ? __pfx_mutex_unlock+0x10/0x10 ? __pfx_do_recvmsg+0x10/0x10 [libceph] ceph_con_process_message+0x1f1/0x650 [libceph] process_message+0x1e/0x450 [libceph] ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] ? save_fpregs_to_fpstate+0xb0/0x230 ? raw_spin_rq_unlock+0x17/0xa0 ? finish_task_switch.isra.0+0x13b/0x760 ? __switch_to+0x385/0xda0 ? __kasan_check_write+0x14/0x30 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 ceph_con_workfn+0x248/0x10c0 [libceph] process_one_work+0x629/0xf80 ? __kasan_check_write+0x14/0x30 worker_thread+0x87f/0x1570 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_try_to_wake_up+0x10/0x10 ? kasan_print_address_stack_frame+0x1f7/0x280 ? __pfx_worker_thread+0x10/0x10 kthread+0x396/0x830 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? __pfx_kthread+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? recalc_sigpending+0x180/0x210 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3f7/0x610 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x385/0xda0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 [ idryomov: replace if statements with ceph_decode_need() for payload_len and result_msg_len ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43409 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kprobes: avoid crash when rmmod/insmod after ftrace killedAfter we hit ftrace is killed by some errors, the kernel crash ifwe remove modules in which kprobe probes.BUG: unable to handle page fault for address: fffffbfff805000dPGD 817fcc067 P4D 817fcc067 PUD 817fc8067 PMD 101555067 PTE 0Oops: Oops: 0000 [#1] SMP KASAN PTICPU: 4 UID: 0 PID: 2012 Comm: rmmod Tainted: G W OETainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULERIP: 0010:kprobes_module_callback+0x89/0x790RSP: 0018:ffff88812e157d30 EFLAGS: 00010a02RAX: 1ffffffff805000d RBX: dffffc0000000000 RCX: ffffffff86a8de90RDX: ffffed1025c2af9b RSI: 0000000000000008 RDI: ffffffffc0280068RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed1025c2af9aR10: ffff88812e157cd7 R11: 205d323130325420 R12: 0000000000000002R13: ffffffffc0290488 R14: 0000000000000002 R15: ffffffffc0280040FS: 00007fbc450dd740(0000) GS:ffff888420331000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: fffffbfff805000d CR3: 000000010f624000 CR4: 00000000000006f0Call Trace: notifier_call_chain+0xc6/0x280 blocking_notifier_call_chain+0x60/0x90 __do_sys_delete_module.constprop.0+0x32a/0x4e0 do_syscall_64+0x5d/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThis is because the kprobe on ftrace does not correctly handlesthe kprobe_ftrace_disabled flag set by ftrace_kill().To prevent this error, check kprobe_ftrace_disabled in__disarm_kprobe_ftrace() and skip all ftrace related operations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43413 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Fix NULL pointer exception during user_scan()user_scan() invokes updated sas_user_scan() for channel 0, and ifsuccessful, iteratively scans remaining channels (1 to shost->max_channel)via scsi_scan_host_selected() in commit 37c4e72b0651 ("scsi: Fixsas_user_scan() to handle wildcard and multi-channel scans"). However,hisi_sas supports only one channel, and the current value of max_channel is1. sas_user_scan() for channel 1 will trigger the following NULL pointerexception:[ 441.554662] Unable to handle kernel NULL pointer dereference at virtual address 00000000000008b0[ 441.554699] Mem abort info:[ 441.554710] ESR = 0x0000000096000004[ 441.554718] EC = 0x25: DABT (current EL), IL = 32 bits[ 441.554723] SET = 0, FnV = 0[ 441.554726] EA = 0, S1PTW = 0[ 441.554730] FSC = 0x04: level 0 translation fault[ 441.554735] Data abort info:[ 441.554737] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 441.554742] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 441.554747] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 441.554752] user pgtable: 4k pages, 48-bit VAs, pgdp=00000828377a6000[ 441.554757] [00000000000008b0] pgd=0000000000000000, p4d=0000000000000000[ 441.554769] Internal error: Oops: 0000000096000004 [#1] SMP[ 441.629589] Modules linked in: arm_spe_pmu arm_smmuv3_pmu tpm_tis_spi hisi_uncore_sllc_pmu hisi_uncore_pa_pmu hisi_uncore_l3c_pmu hisi_uncore_hha_pmu hisi_uncore_ddrc_pmu hisi_uncore_cpa_pmu hns3_pmu hisi_ptt hisi_pcie_pmu tpm_tis_core spidev spi_hisi_sfc_v3xx hisi_uncore_pmu spi_dw_mmio fuse hclge hclge_common hisi_sec2 hisi_hpre hisi_zip hisi_qm hns3 hisi_sas_v3_hw sm3_ce sbsa_gwdt hnae3 hisi_sas_main uacce hisi_dma i2c_hisi dm_mirror dm_region_hash dm_log dm_mod[ 441.670819] CPU: 46 UID: 0 PID: 6994 Comm: bash Kdump: loaded Not tainted 7.0.0-rc2+ #84 PREEMPT[ 441.691327] pstate: 81400009 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)[ 441.698277] pc : sas_find_dev_by_rphy+0x44/0x118[ 441.702896] lr : sas_find_dev_by_rphy+0x3c/0x118[ 441.707502] sp : ffff80009abbba40[ 441.710805] x29: ffff80009abbba40 x28: ffff082819a40008 x27: ffff082810c37c08[ 441.717930] x26: ffff082810c37c28 x25: ffff082819a40290 x24: ffff082810c37c00[ 441.725054] x23: 0000000000000000 x22: 0000000000000001 x21: ffff082819a40000[ 441.732179] x20: ffff082819a40290 x19: 0000000000000000 x18: 0000000000000020[ 441.739304] x17: 0000000000000000 x16: ffffb5dad6bda690 x15: 00000000ffffffff[ 441.746428] x14: ffff082814c3b26c x13: 00000000ffffffff x12: ffff082814c3b26a[ 441.753553] x11: 00000000000000c0 x10: 000000000000003a x9 : ffffb5dad5ea94f4[ 441.760678] x8 : 000000000000003a x7 : ffff80009abbbab0 x6 : 0000000000000030[ 441.767802] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000[ 441.774926] x2 : ffff08280f35a300 x1 : ffffb5dad7127180 x0 : 0000000000000000[ 441.782053] Call trace:[ 441.784488] sas_find_dev_by_rphy+0x44/0x118 (P)[ 441.789095] sas_target_alloc+0x24/0xb0[ 441.792920] scsi_alloc_target+0x290/0x330[ 441.797010] __scsi_scan_target+0x88/0x258[ 441.801096] scsi_scan_channel+0x74/0xb8[ 441.805008] scsi_scan_host_selected+0x170/0x188[ 441.809615] sas_user_scan+0xfc/0x148[ 441.813267] store_scan+0x10c/0x180[ 441.816743] dev_attr_store+0x20/0x40[ 441.820398] sysfs_kf_write+0x84/0xa8[ 441.824054] kernfs_fop_write_iter+0x130/0x1c8[ 441.828487] vfs_write+0x2c0/0x370[ 441.831880] ksys_write+0x74/0x118[ 441.835271] __arm64_sys_write+0x24/0x38[ 441.839182] invoke_syscall+0x50/0x120[ 441.842919] el0_svc_common.constprop.0+0xc8/0xf0[ 441.847611] do_el0_svc+0x24/0x38[ 441.850913] el0_svc+0x38/0x158[ 441.854043] el0t_64_sync_handler+0xa0/0xe8[ 441.858214] el0t_64_sync+0x1ac/0x1b0[ 441.861865] Code: aa1303e0 97ff70a8 34ffff80 d10a4273 (f9445a75)[ 441.867946] ---[ end trace 0000000000000000 ]---Therefore---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43414 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Completely fix fcport double freeIn qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free().When an error happens, this function is called by qla2x00_sp_release(),when kref_put() releases the first and the last reference.qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport().Doing it one more time after kref_put() is a bad idea.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43416 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc, perf: Check that current->mm is alive before getting user callchainIt may happen that mm is already released, which leads to kernel panic.This adds the NULL check for current->mm, similarly tocommit 20afc60f892d ("x86, perf: Check that current->mm is alive before getting user callchain").I was getting this panic when running a profiling BPF program(profile.py from bcc-tools): [26215.051935] Kernel attempted to read user page (588) - exploit attempt? (uid: 0) [26215.051950] BUG: Kernel NULL pointer dereference on read at 0x00000588 [26215.051952] Faulting instruction address: 0xc00000000020fac0 [26215.051957] Oops: Kernel access of bad area, sig: 11 [#1] [...] [26215.052049] Call Trace: [26215.052050] [c000000061da6d30] [c00000000020fc10] perf_callchain_user_64+0x2d0/0x490 (unreliable) [26215.052054] [c000000061da6dc0] [c00000000020f92c] perf_callchain_user+0x1c/0x30 [26215.052057] [c000000061da6de0] [c0000000005ab2a0] get_perf_callchain+0x100/0x360 [26215.052063] [c000000061da6e70] [c000000000573bc8] bpf_get_stackid+0x88/0xf0 [26215.052067] [c000000061da6ea0] [c008000000042258] bpf_prog_16d4ab9ab662f669_do_perf_event+0xf8/0x274 [...]In addition, move storing the top-level stack entry to genericperf_callchain_user to make sure the top-evel entry is always captured,even if current->mm is NULL.[Maddy: fixed message to avoid checkpatch format style error]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43420 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix i_nlink underrun during async unlinkDuring async unlink, we drop the `i_nlink` counter before we receivethe completion (that will eventually update the `i_nlink`) because "weassume that the unlink will succeed". That is not a bad idea, but itraces against deletions by other clients (or against the completion ofour own unlink) and can lead to an underrun which emits a WARNING likethis one: WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68 Modules linked in: CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drop_nlink+0x50/0x68 lr : ceph_unlink+0x6c4/0x720 sp : ffff80012173bc90 x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680 x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647 x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203 x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365 x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74 x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94 x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002 x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8 Call trace: drop_nlink+0x50/0x68 (P) vfs_unlink+0xb0/0x2e8 do_unlinkat+0x204/0x288 __arm64_sys_unlinkat+0x3c/0x80 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0xa4/0xc8 el0_svc+0x18/0x58 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x154/0x158In ceph_unlink(), a call to ceph_mdsc_submit_request() submits theCEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion.Meanwhile, between this call and the following drop_nlink() call, aworker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT orjust a CEPH_MSG_CLIENT_REPLY (the latter of which could be our owncompletion). These will lead to a set_nlink() call, updating the`i_nlink` counter to the value received from the MDS. If that new`i_nlink` value happens to be zero, it is illegal to decrement itfurther. But that is exactly what ceph_unlink() will do then.The WARNING can be reproduced this way:1. Force async unlink; only the async code path is affected. Having no real clue about Ceph internals, I was unable to find out why the MDS wouldn't give me the "Fxr" capabilities, so I patched get_caps_for_async_unlink() to always succeed. (Note that the WARNING dump above was found on an unpatched kernel, without this kludge - this is not a theoretical bug.)2. Add a sleep call after ceph_mdsc_submit_request() so the unlink completion gets handled by a worker thread before drop_nlink() is called. This guarantees that the `i_nlink` is already zero before drop_nlink() runs.The solution is to skip the counter decrement when it is already zero,but doing so without a lock is still racy (TOCTOU). Sinceceph_fill_inode() and handle_cap_grant() both hold the`ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, thisseems like the proper lock to protect the `i_nlink` updates.I found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using`afs_vnode.cb_lock`). All three have the zero check as well.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43425 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: image: mdc800: kill download URB on timeoutmdc800_device_read() submits download_urb and waits for completion.If the timeout fires and the device has not responded, the functionreturns without killing the URB, leaving it active.A subsequent read() resubmits the same URB while it is stillin-flight, triggering the WARN in usb_submit_urb(): "URB submitted while active"Check the return value of wait_event_timeout() and kill the URB ifit indicates timeout, ensuring the URB is complete before its statusis inspected or the URB is resubmitted.Similar to- commit 372c93131998 ("USB: yurex: fix control-URB timeout handling")- commit b98d5000c505 ("media: rc: iguanair: handle timeouts")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43426 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: renesas_usbhs: fix use-after-free in ISR during device removalIn usbhs_remove(), the driver frees resources (including the pipe array)while the interrupt handler (usbhs_interrupt) is still registered. If aninterrupt fires after usbhs_pipe_remove() but before the driver is fullyunbound, the ISR may access freed memory, causing a use-after-free.Fix this by calling devm_free_irq() before freeing resources. This ensuresthe interrupt handler is both disabled and synchronized (waits for anyrunning ISR to complete) before usbhs_pipe_remove() is called.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43427 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: class: cdc-wdm: fix reordering issue in read code pathQuoting the bug report:Due to compiler optimization or CPU out-of-order execution, thedesc->length update can be reordered before the memmove. If thishappens, wdm_read() can see the new length and call copy_to_user() onuninitialized memory. This also violates LKMM data race rules [1].Fix it by using WRITE_ONCE and memory barriers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43429 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: usbtmc: Use usb_bulk_msg_killable() with user-specified timeoutsThe usbtmc driver accepts timeout values specified by the user in anioctl command, and uses these timeouts for some usb_bulk_msg() calls.Since the user can specify arbitrarily long timeouts andusb_bulk_msg() uses unkillable waits, call usb_bulk_msg_killable()instead to avoid the possibility of the user hanging a kernel threadindefinitely.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43432 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Fix memory leak in xhci_disable_slot()xhci_alloc_command() allocates a command structure and, when thesecond argument is true, also allocates a completion structure.Currently, the error handling path in xhci_disable_slot() only freesthe command structure using kfree(), causing the completion structureto leak.Use xhci_free_command() instead of kfree(). xhci_free_command() correctlyfrees both the command structure and the associated completion structure.Since the command structure is allocated with zero-initialization,command->in_ctx is NULL and will not be erroneously freed byxhci_free_command().This bug was found using an experimental static analysis tool we aredeveloping. The tool is based on the LLVM framework and is specificallydesigned to detect memory management issues. It is currently underactive development and not yet publicly available, but we plan toopen-source it after our research is published.The bug was originally detected on v6.13-rc1 using our static analysistool, and we have verified that the issue persists in the latest mainlinekernel.We performed build testing on x86_64 with allyesconfig using GCC=11.4.0.Since triggering these error paths in xhci_disable_slot() requires specifichardware conditions or abnormal state, we were unable to construct a testcase to reliably trigger these specific error paths at runtime.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43436 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Check endpoint numbers at parsing Scarlett2 mixer interfacesThe Scarlett2 mixer quirk in USB-audio driver may hit a NULLdereference when a malformed USB descriptor is passed, since itassumes the presence of an endpoint in the parsed interface inscarlett2_find_fc_interface(), as reported by fuzzer.For avoiding the NULL dereference, just add the sanity check ofbNumEndpoints and skip the invalid interface.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43439 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cgroup: fix race between task migration and iterationWhen a task is migrated out of a css_set, cgroup_migrate_add_task()first moves it from cset->tasks to cset->mg_tasks via: list_move_tail(&task->cg_list, &cset->mg_tasks);If a css_task_iter currently has it->task_pos pointing to this task,css_set_move_task() calls css_task_iter_skip() to keep the iteratorvalid. However, since the task has already been moved to ->mg_tasks,the iterator is advanced relative to the mg_tasks list instead of theoriginal tasks list. As a result, remaining tasks on cset->tasks, aswell as tasks queued on cset->mg_tasks, can be skipped by iteration.Fix this by calling css_set_skip_task_iters() before unlinkingtask->cg_list from cset->tasks. This advances all active iterators tothe next task on cset->tasks, so iteration continues correctly evenwhen a task is concurrently being migrated.This race is hard to hit in practice without instrumentation, but itcan be reproduced by artificially slowing down cgroup_procs_show().For example, on an Android device a temporary/sys/kernel/cgroup/cgroup_test knob can be added to inject a delayinto cgroup_procs_show(), and then: 1) Spawn three long-running tasks (PIDs 101, 102, 103). 2) Create a test cgroup and move the tasks into it. 3) Enable a large delay via /sys/kernel/cgroup/cgroup_test. 4) In one shell, read cgroup.procs from the test cgroup. 5) Within the delay window, in another shell migrate PID 102 by writing it to a different cgroup.procs file.Under this setup, cgroup.procs can intermittently show only PID 101while skipping PID 103. Once the migration completes, reading thefile again shows all tasks as expected.Note that this change does not allow removing the existingcss_set_skip_task_iters() call in css_set_move_task(). The new callin cgroup_migrate_add_task() only handles iterators that are racingwith migration while the task is still on cset->tasks. Iterators mayalso start after the task has been moved to cset->mg_tasks. If wedropped css_set_skip_task_iters() from css_set_move_task(), suchiterators could keep task_pos pointing to a migrating task, causingcss_task_iter_advance() to malfunction on the destination css_set,up to and including crashes or infinite loops.The race window between migration and iteration is very small, andcss_task_iter is not on a hot path. In the worst case, when aniterator is positioned on the first thread of the migrating process,cgroup_migrate_add_task() may have to skip multiple tasks viacss_set_skip_task_iters(). However, this only happens when migrationand iteration actually race, so the performance impact is negligiblecompared to the correctness fix provided here.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43445 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:e1000/e1000e: Fix leak in DMA error cleanupIf an error is encountered while mapping TX buffers, the driver shouldunmap any buffers already mapped for that skb.Because count is incremented after a successful mapping, it will alwaysmatch the correct number of unmappings needed when dma_error is reached.Decrementing count before the while loop in dma_error causes anoff-by-one error. If any mapping was successful before an unsuccessfulmapping, exactly one DMA mapping would leak.In these commits, a faulty while condition caused an infinite loop indma_error:Commit 03b1320dfcee ("e1000e: remove use of skb_dma_map from e1000edriver")Commit 602c0554d7b0 ("e1000: remove use of skb_dma_map from e1000 driver")Commit c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests ofunsigned in *_tx_map()") fixed the infinite loop, but introduced theoff-by-one error.This issue may still exist in the igbvf driver, but I did not address itin this patch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43448 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: Fix race bug in nvme_poll_irqdisable()In the following scenario, pdev can be disabled between (1) and (3) by(2). This sets pdev->msix_enabled = 0. Then, pci_irq_vector() willreturn MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2).This causes IRQ warning because it tries to enable INTx IRQ that hasnever been disabled before.To fix this, save IRQ number into a local variable and ensuredisable_irq() and enable_irq() operate on the same IRQ number. Even ifpci_free_irq_vectors() frees the IRQ concurrently, disable_irq() andenable_irq() on a stale IRQ number is still valid and safe, and thedepth accounting reamins balanced.task 1:nvme_poll_irqdisable() disable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(1) enable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(3)task 2:nvme_reset_work() nvme_dev_disable() pdev->msix_enable = 0; ...(2)crash log:------------[ cut here ]------------Unbalanced enable for IRQ 10WARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26Modules linked in:CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014Workqueue: kblockd blk_mq_timeout_workRIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9RSP: 0018:ffffc900001bf550 EFLAGS: 00010046RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0Call Trace: enable_irq+0x121/0x1e0 kernel/irq/manage.c:797 nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494 nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744 blk_mq_rq_timed_out block/blk-mq.c:1653 [inline] blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721 bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292 __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline] sbitmap_for_each_set include/linux/sbitmap.h:290 [inline] bt_for_each block/blk-mq-tag.c:324 [inline] blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536 blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 irq event stamp: 74478hardirqs last enabled at (74477): [] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline]hardirqs last enabled at (74477): [] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202hardirqs last disabled at (74478): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]hardirqs last disabled at (74478): [] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162softirqs last enabled at (74304): [] __do_softirq kernel/softirq.c:656 [inline]softirqs last enabled at (74304): [] invoke_softirq kernel/softirq.c:496 [inline]softirqs last enabled at (74304): [] __irq_exit_rcu+0xdc/0x120---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43449 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_setdev->online_queues is a count incremented in nvme_init_queue. Thus,valid indices are 0 through dev->online_queues − 1.This patch fixes the loop condition to ensure the index stays within thevalid range. Index 0 is excluded because it is the admin queue.KASAN splat:==================================================================BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline]BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014Workqueue: nvme-reset-wq nvme_reset_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xea/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xce/0x5d0 mm/kasan/report.c:482 kasan_report+0xdc/0x110 mm/kasan/report.c:595 __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c:379 nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c:3252 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 34 on cpu 1 at 4.241550s: kasan_save_stack+0x2c/0x60 mm/kasan/common.c:57 kasan_save_track+0x1c/0x70 mm/kasan/common.c:78 kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c:570 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5657 [inline] __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c:5663 kmalloc_array_node_noprof include/linux/slab.h:1075 [inline] nvme_pci_alloc_dev drivers/nvme/host/pci.c:3479 [inline] nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534 local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c:324 pci_call_probe drivers/pci/pci-driver.c:392 [inline] __pci_device_probe drivers/pci/pci-driver.c:417 [inline] pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c:451 call_driver_probe drivers/base/dd.c:583 [inline] really_probe+0x29b/0xb70 drivers/base/dd.c:661 __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c:803 driver_probe_device+0x56/0x1f0 drivers/base/dd.c:833 __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c:1159 async_run_entry_fn+0xa6/0x4b0 kernel/async.c:129 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246The buggy address belongs to the object at ffff88800592a000 which belongs to the cache kmalloc-2k of size 2048The buggy address is located 244 bytes to the right of allocated 1152-byte region [ffff88800592a000, ffff88800592a480)The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff)page_type: f5(slab)raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000head: 000fffffc0000040 ffff888001042000 00000---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43450 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table()nfnl_cthelper_dump_table() has a 'goto restart' that jumps to a labelinside the for loop body. When the "last" helper saved in cb->args[1]is deleted between dump rounds, every entry fails the (cur != last)check, so cb->args[1] is never cleared. The for loop finishes withcb->args[0] == nf_ct_helper_hsize, and the 'goto restart' jumps backinto the loop body bypassing the bounds check, causing an 8-byteout-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize].The 'goto restart' block was meant to re-traverse the current bucketwhen "last" is no longer found, but it was placed after the for loopinstead of inside it. Move the block into the for loop body so thatthe restart only occurs while cb->args[0] is still within bounds. BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131 Call Trace: nfnl_cthelper_dump_table+0x9f/0x1b0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 sock_recvmsg+0xde/0xf0 __sys_recvfrom+0x150/0x200 __x64_sys_recvfrom+0x76/0x90 do_syscall_64+0xc3/0x6e0 Allocated by task 1: __kvmalloc_node_noprof+0x21b/0x700 nf_ct_alloc_hashtable+0x65/0xd0 nf_conntrack_helper_init+0x21/0x60 nf_conntrack_init_start+0x18d/0x300 nf_conntrack_standalone_init+0x12/0xc0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43451 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_queue: fix entry leak in bridge verdict error pathnfqnl_recv_verdict() calls find_dequeue_entry() to remove the queueentry from the queue data structures, taking ownership of the entry.For PF_BRIDGE packets, it then calls nfqa_parse_bridge() to parse VLANattributes. If nfqa_parse_bridge() returns an error (e.g. NFQA_VLANpresent but NFQA_VLAN_TCI missing), the function returns immediatelywithout freeing the dequeued entry or its sk_buff.This leaks the nf_queue_entry, its associated sk_buff, and all heldreferences (net_device refcounts, struct net refcount). Repeatedtriggering exhausts kernel memory.Fix this by dropping the entry via nfqnl_reinject() with NF_DROP verdicton the error path, consistent with other error handling in this file.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43452 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: guard option walkers against 1-byte tail readsWhen the last byte of options is a non-single-byte option kind, walkersthat advance with i += op[i + 1] ? : 1 can read op[i + 1] past the endof the option area.Add an explicit i == optlen - 1 check before dereferencing op[i + 1]in xt_tcpudp and xt_dccp option walkers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43453 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop()pipapo_drop() passes rulemap[i + 1].n to pipapo_unmap() as theto_offset argument on every iteration, including the last one wherei == m->field_count - 1. This reads one element past the end of thestack-allocated rulemap array (declared as rulemap[NFT_PIPAPO_MAX_FIELDS]with NFT_PIPAPO_MAX_FIELDS == 16).Although pipapo_unmap() returns early when is_last is true withoutusing the to_offset value, the argument is evaluated at the call sitebefore the function body executes, making this a genuine out-of-boundsstack read confirmed by KASAN: BUG: KASAN: stack-out-of-bounds in pipapo_drop+0x50c/0x57c [nf_tables] Read of size 4 at addr ffff8000810e71a4 This frame has 1 object: [32, 160) 'rulemap' The buggy address is at offset 164 -- exactly 4 bytes past the end of the rulemap array.Pass 0 instead of rulemap[i + 1].n on the last iteration to avoidthe out-of-bounds read.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43456 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: fix type confusion in bond_setup_by_slave()kernel BUG at net/core/skbuff.c:2306!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTIRIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306RSP: 0018:ffffc90004aff760 EFLAGS: 00010293RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0eRDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0Call Trace: ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900 dev_hard_header include/linux/netdevice.h:3439 [inline] packet_snd net/packet/af_packet.c:3028 [inline] packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592 ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646 __sys_sendmsg+0x170/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fe1a0e6c1a9When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond,bond_setup_by_slave() directly copies the slave's header_ops to thebond device: bond_dev->header_ops = slave_dev->header_ops;This causes a type confusion when dev_hard_header() is later calledon the bond device. Functions like ipgre_header(), ip6gre_header(),all usenetdev_priv(dev) to access their device-specific private data. Whencalled with the bond device, netdev_priv() returns the bond's privatedata (struct bonding) instead of the expected type (e.g. structip_tunnel), leading to garbage values being read and kernel crashes.Fix this by introducing bond_header_ops with wrapper functions thatdelegate to the active slave's header_ops using the slave's owndevice. This ensures netdev_priv() in the slave's header functionsalways receives the correct device.The fix is placed in the bonding driver rather than individual devicedrivers, as the root cause is bond blindly inheriting header_ops fromthe slave without considering that these callbacks expect a specificnetdev_priv() layout.The type confusion can be observed by adding a printk inipgre_header() and running the following commands: ip link add dummy0 type dummy ip addr add 10.0.0.1/24 dev dummy0 ip link set dummy0 up ip link add gre1 type gre local 10.0.0.1 ip link add bond1 type bond mode active-backup ip link set gre1 master bond1 ip link set gre1 up ip link set bond1 up ip addr add fe80::1/64 dev bond1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43458 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: caif: hold tty->link reference in ldisc_open and ser_releaseA reproducer triggers a KASAN slab-use-after-free in pty_write_room()when caif_serial's TX path calls tty_write_room(). The faulting accessis on tty->link->port.Hold an extra kref on tty->link for the lifetime of the caif_serial linediscipline: get it in ldisc_open() and drop it in ser_release(), andalso drop it on the ldisc_open() error path.With this change applied, the reproducer no longer triggers the UAF inmy testing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43459 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: soc-core: flush delayed work before removing DAIs and widgetsWhen a sound card is unbound while a PCM stream is open, ause-after-free can occur in snd_soc_dapm_stream_event(), called fromthe close_delayed_work workqueue handler.During unbind, snd_soc_unbind_card() flushes delayed work and thencalls soc_cleanup_card_resources(). Inside cleanup,snd_card_disconnect_sync() releases all PCM file descriptors, andthe resulting PCM close path can call snd_soc_dapm_stream_stop()which schedules new delayed work with a pmdown_time timer delay.Since this happens after the flush in snd_soc_unbind_card(), thenew work is not caught. soc_remove_link_components() then freesDAPM widgets before this work fires, leading to the use-after-free.The existing flush in soc_free_pcm_runtime() also cannot help as itruns after soc_remove_link_components() has already freed the widgets.Add a flush in soc_cleanup_card_resources() aftersnd_card_disconnect_sync() (after which no new PCM closes canschedule further delayed work) and before soc_remove_link_dais()and soc_remove_link_components() (which tear down the structures thedelayed work accesses).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43466 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix DMA FIFO desync on error CQE SQ recoveryIn case of a TX error CQE, a recovery flow is triggered,mlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc,desyncing the DMA FIFO producer and consumer.After recovery, the producer pushes new DMA entries at the olddma_fifo_pc, while the consumer reads from position 0.This causes us to unmap stale DMA addresses from before the recovery.The DMA FIFO is a purely software construct with no HW counterpart.At the point of reset, all WQEs have been flushed so dma_fifo_cc isalready equal to dma_fifo_pc. There is no need to reset either counter,similar to how skb_fifo pc/cc are untouched.Remove the 'dma_fifo_cc = 0' reset.This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90 Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: ? __warn+0x7d/0x110 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0x16d/0x180 ? handle_bug+0x4f/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 ? iommu_dma_unmap_page+0x2e/0x90 dma_unmap_page_attrs+0x10d/0x1b0 mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core] mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core] mlx5e_napi_poll+0x8b/0xac0 [mlx5_core] __napi_poll+0x24/0x190 net_rx_action+0x32a/0x3b0 ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core] ? notifier_call_chain+0x35/0xa0 handle_softirqs+0xc9/0x270 irq_exit_rcu+0x71/0xd0 common_interrupt+0x7f/0xa0 asm_common_interrupt+0x22/0x40

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43469 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xprtrdma: Decrement re_receiving on the early exit pathsIn the event that rpcrdma_post_recvs() fails to create a work request(due to memory allocation failure, say) or otherwise exits early, weshould decrement ep->re_receiving before returning. Otherwise we willhang in rpcrdma_xprt_drain() as re_receiving will never reach zero andthe completion will never be triggered.On a system with high memory pressure, this can appear as the followinghung task: INFO: task kworker/u385:17:8393 blocked for more than 122 seconds. Tainted: G S E 6.19.0 #3 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u385:17 state:D stack:0 pid:8393 tgid:8393 ppid:2 task_flags:0x4248060 flags:0x00080000 Workqueue: xprtiod xprt_autoclose [sunrpc] Call Trace: __schedule+0x48b/0x18b0 ? ib_post_send_mad+0x247/0xae0 [ib_core] schedule+0x27/0xf0 schedule_timeout+0x104/0x110 __wait_for_common+0x98/0x180 ? __pfx_schedule_timeout+0x10/0x10 wait_for_completion+0x24/0x40 rpcrdma_xprt_disconnect+0x444/0x460 [rpcrdma] xprt_rdma_close+0x12/0x40 [rpcrdma] xprt_autoclose+0x5f/0x120 [sunrpc] process_one_work+0x191/0x3e0 worker_thread+0x2e3/0x420 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x273/0x2b0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43472 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:unshare: fix unshare_fs() handlingThere's an unpleasant corner case in unshare(2), when we have aCLONE_NEWNS in flags and current->fs hadn't been shared at all; in thatcase copy_mnt_ns() gets passed current->fs instead of a private copy,which causes interesting warts in proof of correctness]> I guess if private means fs->users == 1, the condition could still be true.Unfortunately, it's worse than just a convoluted proof of correctness.Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS(and current->fs->users == 1).We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds andflips current->fs->{pwd,root} to corresponding locations in the new namespace.Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it'sdestroyed and its mount tree is dissolved, but... current->fs->root andcurrent->fs->pwd are both left pointing to now detached mounts.They are pinning those, so it's not a UAF, but it leaves the callingprocess with unshare(2) failing with -ENOMEM _and_ leaving it withpwd and root on detached isolated mounts. The last part is clearly a bug.There is other fun related to that mess (races with pivot_root(), includingthe one between pivot_root() and fork(), of all things), but this oneis easy to isolate and fix - treat CLONE_NEWNS as "allocate a newfs_struct even if it hadn't been shared in the first place". Sure, we couldgo for something like "if both CLONE_NEWNS *and* one of the things that mightend up failing after copy_mnt_ns() call in create_new_namespaces() are set,force allocation of new fs_struct", but let's keep it simple - the costof copy_fs_struct() is trivial.Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* getsa freshly allocated fs_struct, yet to be attached to anything. Thatseriously simplifies the analysis...FWIW, that bug had been there since the introduction of unshare(2) ;-/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43475 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: storvsc: Fix scheduling while atomic on PREEMPT_RTThis resolves the follow splat and lock-up when running with PREEMPT_RTenabled on Hyper-V:[ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002[ 415.140822] INFO: lockdep is turned off.[ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common[ 415.140846] Preemption disabled at:[ 415.140847] [] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc][ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)}[ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024[ 415.140857] Call Trace:[ 415.140861] [ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc][ 415.140863] dump_stack_lvl+0x91/0xb0[ 415.140870] __schedule_bug+0x9c/0xc0[ 415.140875] __schedule+0xdf6/0x1300[ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980[ 415.140879] ? rcu_is_watching+0x12/0x60[ 415.140883] schedule_rtlock+0x21/0x40[ 415.140885] rtlock_slowlock_locked+0x502/0x1980[ 415.140891] rt_spin_lock+0x89/0x1e0[ 415.140893] hv_ringbuffer_write+0x87/0x2a0[ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0[ 415.140900] ? rcu_is_watching+0x12/0x60[ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc][ 415.140904] ? HARDIRQ_verbose+0x10/0x10[ 415.140908] ? __rq_qos_issue+0x28/0x40[ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod][ 415.140926] __blk_mq_issue_directly+0x4a/0xc0[ 415.140928] blk_mq_issue_direct+0x87/0x2b0[ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440[ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0[ 415.140935] __blk_flush_plug+0xf4/0x150[ 415.140940] __submit_bio+0x2b2/0x5c0[ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360[ 415.140946] submit_bio_noacct_nocheck+0x272/0x360[ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4][ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4][ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4][ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4][ 415.141060] generic_perform_write+0x14e/0x2c0[ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4][ 415.141083] vfs_write+0x2ca/0x570[ 415.141087] ksys_write+0x76/0xf0[ 415.141089] do_syscall_64+0x99/0x1490[ 415.141093] ? rcu_is_watching+0x12/0x60[ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0[ 415.141097] ? rcu_is_watching+0x12/0x60[ 415.141098] ? lock_release+0x1f0/0x2a0[ 415.141100] ? rcu_is_watching+0x12/0x60[ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0[ 415.141103] ? rcu_is_watching+0x12/0x60[ 415.141104] ? __schedule+0xb34/0x1300[ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170[ 415.141109] ? do_nanosleep+0x8b/0x160[ 415.141111] ? hrtimer_nanosleep+0x89/0x100[ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10[ 415.141116] ? xfd_validate_state+0x26/0x90[ 415.141118] ? rcu_is_watching+0x12/0x60[ 415.141120] ? do_syscall_64+0x1e0/0x1490[ 415.141121] ? do_syscall_64+0x1e0/0x1490[ 415.141123] ? rcu_is_watching+0x12/0x60[ 415.141124] ? do_syscall_64+0x1e0/0x1490[ 415.141125] ? do_syscall_64+0x1e0/0x1490[ 415.141127] ? irqentry_exit+0x140/0---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43476 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas()sizeof(num) evaluates to sizeof(size_t) (8 bytes on 64-bit) insteadof the intended __be32 element size (4 bytes). Use sizeof(*meas) tocorrectly match the buffer element type.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43480 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisitionThe acp3x_5682_init() function did not check the return value ofclk_get(), which could lead to dereferencing error pointers inrt5682_clk_enable().Fix this by:1. Changing clk_get() to the device-managed devm_clk_get().2. Adding proper IS_ERR() checks for both clock acquisitions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43483 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activatedExplicitly set/clear CR8 write interception when AVIC is (de)activated tofix a bug where KVM leaves the interception enabled after AVIC isactivated. E.g. if KVM emulates INIT=>WFS while AVIC is deactivated, CR8will remain intercepted in perpetuity.On its own, the dangling CR8 intercept is "just" a performance issue, butcombined with the TPR sync bug fixed by commit d02e48830e3f ("KVM: SVM:Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active"), the dangingintercept is fatal to Windows guests as the TPR seen by hardware getswildly out of sync with reality.Note, VMX isn't affected by the bug as TPR_THRESHOLD is explicitly ignoredwhen Virtual Interrupt Delivery is enabled, i.e. when APICv is active inKVM's world. I.e. there's no need to trigger update_cr8_intercept(), thisis firmly an SVM implementation flaw/detail.WARN if KVM gets a CR8 write #VMEXIT while AVIC is active, as KVM shouldnever enter the guest with AVIC enabled and CR8 writes intercepted.[Squash fix to avic_deactivate_vmcb. - Paolo]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43484 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mmc: core: Avoid bitfield RMW for claim/retune flagsMove claimed and retune control flags out of the bitfield word toavoid unrelated RMW side effects in asynchronous contexts.The host->claimed bit shared a word with retune flags. Writes to claimedin __mmc_claim_host() or retune_now in mmc_mq_queue_rq() can overwriteother bits when concurrent updates happen in other contexts, triggeringspurious WARN_ON(!host->claimed). Convert claimed, can_retune,retune_now and retune_paused to bool to remove shared-word coupling.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43492 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl()Yiming reports an integer underflow in mpi_read_raw_from_sgl() whensubtracting "lzeros" from the unsigned "nbytes".For this to happen, the scatterlist "sgl" needs to occupy more bytesthan the "nbytes" parameter and the first "nbytes + 1" bytes of thescatterlist must be zero. Under these conditions, the while loopiterating over the scatterlist will count more zeroes than "nbytes",subtract the number of zeroes from "nbytes" and cause the underflow.When commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originallyintroduced the bug, it couldn't be triggered because all callers ofmpi_read_raw_from_sgl() passed a scatterlist whose length was equal to"nbytes".However since commit 63ba4d67594a ("KEYS: asymmetric: Use new cryptointerface without scatterlists"), the underflow can now actually betriggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with alarger "out_len" than "in_len" and filling the "in" buffer with zeroes,crypto_akcipher_sync_prep() will create an all-zero scatterlist used forboth the "src" and "dst" member of struct akcipher_request and therebyfulfil the conditions to trigger the bug: sys_keyctl() keyctl_pkey_e_d_s() asymmetric_key_eds_op() software_key_eds_op() crypto_akcipher_sync_encrypt() crypto_akcipher_sync_prep() crypto_akcipher_encrypt() rsa_enc() mpi_read_raw_from_sgl()To the user this will be visible as a DoS as the kernel spins forever,causing soft lockup splats as a side effect.Fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43493 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: pcrypt - Fix handling of MAY_BACKLOG requestsMAY_BACKLOG requests can return EBUSY. Handle them by checkingfor that value and filtering out EINPROGRESS notifications.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43496 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peekedWhen red qdisc has children (eg qfq qdisc) whose peek() callback isqdisc_peek_dequeued(), we could get a kernel panic. When the parent of suchqdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb fromits child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue.[ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f][ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full)[ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011[ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq][ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d[ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216[ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000[ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048[ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078[ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000[ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200[ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000[ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0[ 78.671585][ T363] PKRU: 55555554[ 78.671713][ T363] Call Trace:[ 78.671843][ T363] [ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq][ 78.672148][ T363] ? __pfx__printk+0x10/0x10[ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5[ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0[ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5[ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0[ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red][ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5[ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf][ 78.673566][ T363] __qdisc_run+0x169/0x1900The right thing to do in #1b is to grab the skb off gso_skb queue.This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked()method instead.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43502 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/rds: handle zerocopy send cleanup before the message is queuedA zerocopy send can fail after user pages have been pinned but beforethe message is attached to the sending socket.The purge path currently infers zerocopy state from rm->m_rs, so anunqueued message can be cleaned up as if it owned normal payload pages.However, zerocopy ownership is really determined by the presence ofop_mmp_znotifier, regardless of whether the message has reached thesocket queue.Capture op_mmp_znotifier up front in rds_message_purge() and use it asthe cleanup discriminator. If the message is already associated with asocket, keep the existing completion path. Otherwise, drop the pinnedpage accounting directly and release the notifier before putting thepayload pages.This keeps early send failure cleanup consistent with the zerocopylifetime rules without changing the normal queued completion path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-43896 Severity: Moderate CVSS3 score: 5.5

Description: jq is a command-line JSON processor. In 1.8.1 and earlier, unbounded recursion in jv_object_merge_recursive() allows a crafted jq program to crash the process with a segfault. The function is reachable through the * operator when both operands are objects.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
jq > 0-0 (version in image is 1.6-150000.3.12.1).

CVE-2026-44777 Severity: Moderate CVSS3 score: 5.5

Description: jq is a command-line JSON processor. In 1.8.2rc1 and earlier, the ordinary module loader recurses without cycle detection when twootherwise valid modules include each other.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
jq > 0-0 (version in image is 1.6-150000.3.12.1).

CVE-2026-45834 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()Add the same NULL guard already present inl2cap_sock_resume_cb() and l2cap_sock_ready_cb().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45835 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb()Add the same NULL guard already present inl2cap_sock_resume_cb() and l2cap_sock_ready_cb().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45836 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb()Add the same NULL guard already present inl2cap_sock_resume_cb() and l2cap_sock_ready_cb().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45838 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix end-of-list detection in cgroup_storage_get_next_key()list_next_entry() never returns NULL -- when the current element is thelast entry it wraps to the list head via container_of(). The subsequentNULL check is therefore dead code and get_next_key() never returns-ENOENT for the last element, instead reading storage->key from a boguspointer that aliases internal map fields and copying the result touserspace.Replace it with list_entry_is_head() so the function correctly returns-ENOENT when there are no more entries.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45839 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec()CO-RE accessor strings are colon-separated indices that describe a pathfrom a root BTF type to a target field, e.g. "0:1:2" walks throughnested struct members. bpf_core_parse_spec() parses each component withsscanf("%d"), so negative values like -1 are silently accepted. Thesubsequent bounds checks (access_idx >= btf_vlen(t)) only guard theupper bound and always pass for negative values because C integerpromotion converts the __u16 btf_vlen result to int, making thecomparison (int)(-1) >= (int)(N) false for any positive N.When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff,producing an out-of-bounds read far past the members array. A craftedBPF program with a negative CO-RE accessor on any struct that exists invmlinux BTF (e.g. task_struct) crashes the kernel deterministicallyduring BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y(default on major distributions). The bug is reachable with CAP_BPF: BUG: unable to handle page fault for address: ffffed11818b6626 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full) RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354) RAX: 00000000ffffffff Call Trace: bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321) bpf_core_apply (kernel/bpf/btf.c:9507) check_core_relo (kernel/bpf/verifier.c:19475) bpf_check (kernel/bpf/verifier.c:26031) bpf_prog_load (kernel/bpf/syscall.c:3089) __sys_bpf (kernel/bpf/syscall.c:6228) CO-RE accessor indices are inherently non-negative (struct member index,array element index, or enumerator index), so reject them immediatelyafter parsing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45847 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: remove WARN_ON_ONCE when accessing forward path arrayAlthough unlikely, recent support for IPIP tunnels increases chances ofreaching this WARN_ON_ONCE if userspace manages to build a sufficientlylong forward path.Remove it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45848 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix NULL sock in aa_sock_file_permDeal with the potential that sock and sock-sk can be NULL duringsocket setup or teardown. This could lead to an oops. The fix for NULLpointer dereference in __unix_needs_revalidation shows this is atleast possible for af_unix sockets. While the fix for af_unix socketsapplies for newer mediation this is still the fall back path for olderaf_unix mediation and other sockets, so ensure it is covered.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45850 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: skip ipv6 extension headers for csum checksProtocol checksum validation fails for IPv6 if there are extensionheaders before the protocol header. iph->len already contains itsoffset, so use it to fix the problem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ata: libata-scsi: avoid Non-NCQ command starvationWhen a non-NCQ command is issued while NCQ commands are being executed,ata_scsi_qc_issue() indicates to the SCSI layer that the command issuingshould be deferred by returning SCSI_MLQUEUE_XXX_BUSY. This commanddeferring is correct and as mandated by the ACS specifications sinceNCQ and non-NCQ commands cannot be mixed.However, in the case of a host adapter using multiple submission queues,when the target device is under a constant load of NCQ commands, thereare no guarantees that requeueing the non-NCQ command will be executedlater and it may be deferred again repeatedly as other submission queuescan constantly issue NCQ commands from different CPUs ahead of thenon-NCQ command. This can lead to very long delays for the execution ofnon-NCQ commands, and even complete starvation for these commands in theworst case scenario.Since the block layer and the SCSI layer do not distinguish betweenqueueable (NCQ) and non queueable (non-NCQ) commands, libata-scsi SATimplementation must ensure forward progress for non-NCQ commands in thepresence of NCQ command traffic. This is similar to what SAS HBAs with ahardware/firmware based SAT implementation do.Implement such forward progress guarantee by limiting requeueing ofnon-NCQ commands from ata_scsi_qc_issue(): when a non-NCQ command isreceived and NCQ commands are in-flight, do not force a requeue of thenon-NCQ command by returning SCSI_MLQUEUE_XXX_BUSY and instead return 0to indicate that the command was accepted but hold on to the qc usingthe new deferred_qc field of struct ata_port.This deferred qc will be issued using the work item deferred_qc_workrunning the function ata_scsi_deferred_qc_work() once all in-flightcommands complete, which is checked with the port qc_defer() callbackreturn value indicating that no further delay is necessary. This checkis done using the helper function ata_scsi_schedule_deferred_qc() whichis called from ata_scsi_qc_complete(). This thus excludes this mechanismfrom all internal non-NCQ commands issued by ATA EH.When a port deferred_qc is non NULL, that is, the port has a commandwaiting for the device queue to drain, the issuing of all incomingcommands (both NCQ and non-NCQ) is deferred using the regular busymechanism. This simplifies the code and also avoids potential denial ofservice problems if a user issues too many non-NCQ commands.Finally, whenever ata EH is scheduled, regardless of the reason, adeferred qc is always requeued so that it can be retried once EHcompletes. This is done by calling the functionata_scsi_requeue_deferred_qc() from ata_eh_set_pending(). This avoidsthe need for any special processing for the deferred qc in case of NCQerror, link or device reset, or device timeout.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: csiostor: Fix dereference of null pointer rnThe error exit path when rn is NULL ends up deferencing the null pointer rnvia the use of the macro CSIO_INC_STATS. Fix this by adding a new errorreturn path label after the use of the macro to avoid the deference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45858 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1When allocating initialized blocks from a large unwritten extent, orwhen splitting an unwritten extent during end I/O and converting it toinitialized, there is currently a potential issue of stale data if theextent needs to be split in the middle. 0 A B N [UUUUUUUUUUUU] U: unwritten extent [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initializedext4_split_extent() first try to split this extent at B withEXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, butext4_split_extent_at() failed to split this extent due to temporary lackof space. It zeroout B to N and mark the entire extent from 0 to Nas written. 0 A B N [WWWWWWWWWWWW] W: written extent [SSDDDDDDDDZZ] Z: zeroed, S: stale dataext4_split_extent() then try to split this extent at A withEXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and lefta stale written extent from 0 to A. 0 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ]Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at()when splitting at B, don't convert the entire extent to written and leftit as unwritten after zeroing out B to N. The remaining work is justlike the standard two-part split. ext4_split_extent() will pass theEXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for thesecond time, allowing it to properly handle the split. If the split issuccessful, it will keep extent from 0 to A as unwritten.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45868 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: single: fix refcount leak in pcs_add_gpio_func()of_parse_phandle_with_args() returns a device_node pointer with refcountincremented in gpiospec.np. The loop iterates through all phandles butnever releases the reference, causing a refcount leak on each iteration.Add of_node_put() calls to release the reference after extracting theneeded arguments and on the error path when devm_kzalloc() fails.This bug was detected by our static analysis tool and verified by mycode review.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45893 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: Fix & Optimize table creation from possibly unaligned memorySource blob may come from userspace and might be unaligned.Try to optize the copying process by avoiding unaligned memory accesses.- Added Fixes tag- Added "Fix &" to description as this doesn't just optimize but fixes a potential unaligned memory access[jj: remove duplicate word "convert" in comment trigger checkpatch warning]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45900 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: caam - fix netdev memory leak in dpaa2_caam_probeWhen commit 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure indpaa2") converted embedded net_device to dynamically allocated pointers,it added cleanup in dpaa2_dpseci_disable() but missed adding cleanup indpaa2_dpseci_free() for error paths.This causes memory leaks when dpaa2_dpseci_dpio_setup() fails during probedue to DPIO devices not being ready yet. The kernel's deferred probemechanism handles the retry successfully, but the netdevs allocated duringthe failed probe attempt are never freed, resulting in kmemleak reportsshowing multiple leaked netdev-related allocations all traced back todpaa2_caam_probe().Fix this by preserving the CPU mask of allocated netdevs during setup andusing it for cleanup in dpaa2_dpseci_free(). This approach ensures thatonly the CPUs that actually had netdevs allocated will be cleaned up,avoiding potential issues with CPU hotplug scenarios.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45905 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: fix ip_rt_bug race in icmp_route_lookup reverse pathicmp_route_lookup() performs multiple route lookups to find a suitableroute for sending ICMP error messages, with special handling for XFRM(IPsec) policies.The lookup sequence is:1. First, lookup output route for ICMP reply (dst = original src)2. Pass through xfrm_lookup() for policy check3. If blocked (-EPERM) or dst is not local, enter "reverse path"4. In reverse path, call xfrm_decode_session_reverse() to get fl4_dec which reverses the original packet's flow (saddr<->daddr swapped)5. If fl4_dec.saddr is local (we are the original destination), use __ip_route_output_key() for output route lookup6. If fl4_dec.saddr is NOT local (we are a forwarding node), use ip_route_input() to simulate the reverse packet's input path7. Finally, pass rt2 through xfrm_lookup() with XFRM_LOOKUP_ICMP flagThe bug occurs in step 6: ip_route_input() is called with fl4_dec.daddr(original packet's source) as destination. If this address becomes localbetween the initial check and ip_route_input() call (e.g., due toconcurrent "ip addr add"), ip_route_input() returns a LOCAL route withdst.output set to ip_rt_bug.This route is then used for ICMP output, causing dst_output() to callip_rt_bug(), triggering a WARN_ON: ------------[ cut here ]------------ WARNING: net/ipv4/route.c:1275 at ip_rt_bug+0x21/0x30, CPU#1 Call Trace: ip_push_pending_frames+0x202/0x240 icmp_push_reply+0x30d/0x430 __icmp_send+0x1149/0x24f0 ip_options_compile+0xa2/0xd0 ip_rcv_finish_core+0x829/0x1950 ip_rcv+0x2d7/0x420 __netif_receive_skb_one_core+0x185/0x1f0 netif_receive_skb+0x90/0x450 tun_get_user+0x3413/0x3fb0 tun_chr_write_iter+0xe4/0x220 ...Fix this by checking rt2->rt_type after ip_route_input(). If it'sRTN_LOCAL, the route cannot be used for output, so treat it as an error.The reproducer requires kernel modification to widen the race window,making it unsuitable as a selftest. It is available at: https://gist.github.com/mrpre/eae853b72ac6a750f5d45d64ddac1e81

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45911 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: fix role switching during resumeIf the role change while we are suspended, the cdns3 driver switches to thenew mode during resume. However, switching to host mode in this contextcauses a NULL pointer dereference.The host role's start() operation registers a xhci-hcd device, but itsprobe is deferred while we are in the resume path. The host role's resume()operation assumes the xhci-hcd device is already probed, which is not thecase, leading to the dereference. Since the start() operation of the newrole is already called, the resume operation can be skipped.So skip the resume operation for the new role if a role switch occursduring resume. Once the resume sequence is complete, the xhci-hcd devicecan be probed in case of host mode.Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208Mem abort info:...Data abort info:...[0000000000000208] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 0000000096000004 [#1] SMPModules linked in:CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPTHardware name: Texas Instruments J7200 EVM (DT)pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : usb_hcd_is_primary_hcd+0x0/0x1clr : cdns_host_resume+0x24/0x5c...Call trace: usb_hcd_is_primary_hcd+0x0/0x1c (P) cdns_resume+0x6c/0xbc cdns3_controller_resume.isra.0+0xe8/0x17c cdns3_plat_resume+0x18/0x24 platform_pm_resume+0x2c/0x68 dpm_run_callback+0x90/0x248 device_resume+0x100/0x24c dpm_resume+0x190/0x2ec dpm_resume_end+0x18/0x34 suspend_devices_and_enter+0x2b0/0xa44 pm_suspend+0x16c/0x5fc state_store+0x80/0xec kobj_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x130/0x1dc vfs_write+0x240/0x370 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0x108 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19cCode: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401)---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.219.1).

CVE-2026-45912 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: don't cache extent during splitting extentCaching extents during the splitting process is risky, as it may resultin stale extents remaining in the status tree. Moreover, in most cases,the corresponding extent block entries are likely already cached beforethe split happens, making caching here not particularly useful.Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this rangeFirst, when ext4_split_extent_at() splits this extent, it truncates theexisting extent and then inserts a new one. During this process, thisextent status entry may be shrunk, and calls to ext4_find_extent() andext4_cache_extents() may occur, which could potentially insert thetruncated range as a hole into the extent status tree. After the splitis completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: holeThen, the outer calling functions will not correct this remaining holeextent either. Finally, if we perform a delayed buffer write on thislatter part, it will re-insert the delayed extent and cause an error inspace accounting.In adition, if the unwritten extent cache is not shrunk during thesplitting, ext4_cache_extents() also conflicts with existing extentswhen caching extents. In the future, we will add checks when cachingextents, which will trigger a warning. Therefore, Do not cache extentsthat are being split.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default

CVE scan

Summary of CVEs affecting the image: